Ticket #564 (closed enhancement: fixed)

Opened 4 years ago

Last modified 3 years ago

Adressing of informal elements

Reported by: cmueller Owned by: vzholudev
Priority: major Milestone: zzz Future zzz
Component: [SI] NTN Version: unknown
Keywords: Cc: kohlhase, frabe, clange, fhorozal
Blocked By: Blocking:
Due to close: Include in GanttChart: no
Dependencies: Due to assign:

Description

The variant module is currently based on document-xml:id#element-xml:id reference.

With MMT the addressing of formal elements is solved. Some suggestions have been made for informal elements. This should be clearly specified and then changed in JOMDoc.

See discussion in  OMDoc trac and on the jomdoc mailing lists (e.g.,  this) for details.

This ticket is future work. The variant module is currently based on OMDoc 1.2.

Change History

follow-up: ↓ 5   Changed 4 years ago by cmueller

This is actually also an issue for the notation module; currently in OMDoc1.2 we are using values such as doc.omdoc#el.id for xref etc.

But for notation tags (and ec) we already allow a syntax el.id#child.id (this is already supported in JOMDoc):

<notation ... xml:id="ntn123">
  <rendering xml:id="rend789"> ... </rendering>
  <rendering xml:id="rend456"> ... </rendering>
</notation>

<tag type="notation" xref="ntn123#rend456" />

follow-up: ↓ 3   Changed 4 years ago by clange

Nesting # does not conform with RFC 3986 (= the official specification of URIs) and thus is evil. Suppose a link to ntn123#rend456 is found in a document http://tntbase.mathweb.org/db/foo.omdoc. By RFC 3986, any decently implemented library will resolve this link to http://tntbase.mathweb.org/db/ntn123#rend456. Also note how the # works. It keeps the client responsible for retrieving the complete document (here: http://tntbase.mathweb.org/db/ntn123). Then, the client is responsible for locating the so-called fragment with the ID rend456 in the downloaded document.

I suppose

  1. you want to realize something that does not easily work with # and fragments
  2. in fact you have already realized it, by a custom implementation in JOMDoc

Thus, this has a lot of similarities with MMT URIs. They are implemented by a custom interpretation of slashes, which, however, does not violate RFC 3986.

Summary: Use / instead of # for any such custom features. # is a bug here.

in reply to: ↑ 2 ; follow-up: ↓ 4   Changed 4 years ago by cmueller

  • component changed from [SI] Lang to [SI] NTN

Replying to clange:

Nesting # does not conform with RFC 3986 (= the official specification of URIs) and thus is evil. Suppose a link to ntn123#rend456 is found in a document http://tntbase.mathweb.org/db/foo.omdoc. By RFC 3986, any decently implemented library will resolve this link to http://tntbase.mathweb.org/db/ntn123#rend456. Also note how the # works. It keeps the client responsible for retrieving the complete document (here: http://tntbase.mathweb.org/db/ntn123). Then, the client is responsible for locating the so-called fragment with the ID rend456 in the downloaded document. I suppose 1. you want to realize something that does not easily work with # and fragments 1. in fact you have already realized it, by a custom implementation in JOMDoc Thus, this has a lot of similarities with MMT URIs. They are implemented by a custom interpretation of slashes, which, however, does not violate RFC 3986. Summary: Use / instead of # for any such custom features. # is a bug here.

I was not proposing the former solution but created this ticket in order to revise it appropriately.

I am a bit confused about the blame, though. If I was the one suggesting the current solution, I have to apologize. I didn't intend to do so and actually never felt experienced enough to judge on this. I was hoping that someone with experiences in this would help at some point.

I suggest

  • to somewhere clearly specify how informal elements are specified from now on,
  • to announce this on the omdoc mailinglist, and
  • to add this refactoring to the agenda for NTN.

in reply to: ↑ 3   Changed 4 years ago by clange

  • cc fhorozal added

Replying to cmueller:

I was not proposing the former solution but created this ticket in order to revise it appropriately.

Not sure who is to blame for introducing the existing state, I'm sorry if I sounded too harsh. I was mainly referring to what you cited in the 1st comment above:

But for notation tags (and ec) we already allow a syntax el.id#child.id (this is already supported in JOMDoc): <notation ... xml:id="ntn123"> <rendering xml:id="rend789"> ... </rendering> <rendering xml:id="rend456"> ... </rendering> </notation> <tag type="notation" xref="ntn123#rend456" />

What I understood from this:

  • The resolution of tag/@xref attributes has already been implemented. (If this is the case, it is a bug, because it violates RFC 3986, and we need a separate ticket for that bug.)
  • The second thing I "understood" may actually have been a misinterpretation of what you wrote. I interpreted the whole comment like that: "In OMDoc 1.2, we only support doc.omdoc#fragment-id (this is right). In JOMDoc we additionally support xref="ntn123#rend456" (this would be a bug). Therefore, we should also discuss whether we need the xref="fragment1#fragment2" elsewhere in (J)OMDoc (this is what I'm trying to avoid here)." This interpretation may have been wrong.

* to somewhere clearly specify how informal elements are specified from now on,

This confuses me, too. I know some outdated bits and pieces about that:

  • The MMT addressing scheme only covers formal stuff, but for OMDoc 1.6 we want to extend its coverage to informal stuff.
  • At some point in time I had the impression that that was a topic on Fulya's agenda (@Fulya: Hi! That's why I Cced you, too), but I'm not sure whether that is the case any longer.

Your plan of what we have to do is perfectly reasonable, and hereby I officially concur with it and ask the others to comment: First get the specification right, and then get all implementations right. (Note that this will affect more than JOMDoc. Krextor will also be affected. But there I'm in a position, which is convenient for all of us: Whatever we will agree about, I will implement it. There, I don't have any of my own requirements.) Besides "my" implementations I see my role in what I tried to start here, i.e. paying special attention to standards-compliance.

Aha, according to #184, both of us are to blame for the ntn123#rend456 syntax :-( Back then, in #184, I didn't react to that, as I thought that ntn123 is an abbreviation for a whole document. I also see that in #149 we had some discussions about the addressing of notations.

in reply to: ↑ 1 ; follow-up: ↓ 6   Changed 4 years ago by dmisev

Replying to cmueller:

But for notation tags (and ec) we already allow a syntax el.id#child.id (this is already supported in JOMDoc):

hm no, this has never been supported in JOMDoc. Probably it's some misunderstanding.

in reply to: ↑ 5 ; follow-ups: ↓ 7 ↓ 9   Changed 4 years ago by cmueller

Replying to dmisev:

Replying to cmueller:

But for notation tags (and ec) we already allow a syntax el.id#child.id (this is already supported in JOMDoc):

hm no, this has never been supported in JOMDoc. Probably it's some misunderstanding.

Mhm, so what is actually implemented? How would I need to write down a tag that references an element "child.id" in a document "doc.id"?

Are tags such as <tag xref="ntn123#ren456" /> supported by JOMDoc? Or what kind of reference can currently be resolved?

Many thanks.

in reply to: ↑ 6   Changed 4 years ago by cmueller

Replying to cmueller:

Replying to dmisev:

Replying to cmueller:

But for notation tags (and ec) we already allow a syntax el.id#child.id (this is already supported in JOMDoc):

hm no, this has never been supported in JOMDoc. Probably it's some misunderstanding.

Mhm, so what is actually implemented? How would I need to write down a tag that references an element "child.id" in a document "doc.id"? Are tags such as <tag xref="ntn123#ren456" /> supported by JOMDoc? Or what kind of reference can currently be resolved? Many thanks.

I am a bit confused now what has been implemented and whether it is what we have specified. Dimitar, I would very much appreciate if you could document tags on a trac wiki page?. This makes it easier for users to understand how they can write down notation tags. Pleae point to the test-cases for illustrations. Many thanks in advance!!!

@Florian/ Michael: This would probably be a good opportunity to specify the addressing of informal elements in OMDoc or -- if already fully done -- to document it somewhere so we can adapt the support for tags in JOMDoc respectively.

follow-up: ↓ 11   Changed 4 years ago by cmueller

See omdoc-dev mailing lists for previous discussions (thread "Proposal for MMT URIs") and  https://svn.omdoc.org/repos/omdoc/trunk/doc/blue/mmturis/note.{tex,pdf} (if this document is still up-to-date).

in reply to: ↑ 6 ; follow-up: ↓ 10   Changed 4 years ago by dmisev

Replying to cmueller:

Mhm, so what is actually implemented? How would I need to write down a tag that references an element "child.id" in a document "doc.id"? Are tags such as <tag xref="ntn123#ren456" /> supported by JOMDoc? Or what kind of reference can currently be resolved? Many thanks.

Well just the normal way of referencing is supported, document-uri#element-id or #element-id if it is in the same document.

in reply to: ↑ 9   Changed 4 years ago by cmueller

Replying to dmisev:

Replying to cmueller:

Mhm, so what is actually implemented? How would I need to write down a tag that references an element "child.id" in a document "doc.id"? Are tags such as <tag xref="ntn123#ren456" /> supported by JOMDoc? Or what kind of reference can currently be resolved? Many thanks.

Well just the normal way of referencing is supported, document-uri#element-id or #element-id if it is in the same document.

okay, I see and that's fine for me.

@Christoph: What are your (JOBAD's) requirements for this. Are you using tags or do you need a different referencing. For my use-cases the current implementation is fine.

in reply to: ↑ 8   Changed 4 years ago by clange

Replying to cmueller:

See omdoc-dev mailing lists for previous discussions (thread "Proposal for MMT URIs") and  https://svn.omdoc.org/repos/omdoc/trunk/doc/blue/mmturis/note.{tex,pdf} (if this document is still up-to-date).

I can only comment very superficially on that, but at a first glance it seems to me that that document is terribly outdated. The MMT URI syntax is quite different now (the graph?theory?symbol URIs are retrievable!), and I suppose that we now simply assume that we have a fully MMT-aware server (and do not need such a translation).

  Changed 3 years ago by nmueller

  • owner changed from nmueller to vzholudev

  Changed 3 years ago by clange

Is this ticket still relevant?

  Changed 3 years ago by dmisev

  • status changed from new to closed
  • resolution set to fixed

I guess it can be closed.

Note: See TracTickets for help on using tickets.