substance / texture

A visual editor for research.
MIT License
1k stars 85 forks source link

Omit ids for elements that can be identified by their context #1083

Open obuchtala opened 5 years ago

obuchtala commented 5 years ago

ATM, we generate a lot of ids, where some of them are not necessary, because the element is uniquely identified by the context. Beyond that, Texture uses ids internally very extensively to 'route' changes to the correct place in the document. When loading or generating JATS, some of the ids could be omitted.

Example:

          <fig id="fig1">
            <label>Figure 1A</label>
            <caption>
              <title>Title</title>
              <p id="fig1-caption-p1">Caption</p>
            </caption>
            <graphic mime-subtype="jpeg" mimetype="image" xlink:href="fig1a.jpg" />
          </fig>

For most elements inside a <fig> we could omit the id (label, title, graphic). Only paragraphs need an id, because there could be more of them. Internally, during import the uniquely identified elements would get a derived id, such as fig1-title.

JGilbert-eLife commented 5 years ago

@oliver---- Can you elaborate on why you'd need to retain the id of the paragraph element? In eLife JATS XML and other examples I've seen, <p> always exists without an id attribute even when there are many of them present in a section or caption.

Thanks,

James

obuchtala commented 5 years ago

Yeah, that is a bit of a special problem in editor land.

While in a single user case, it would be ok to omit all ids, and only retain those necessary for xref'ing, we always have collaboration features on the radar, too. The premise is, if two users opened the same document, they should see the same internal ids, so that their changes can be tracked robustly. The order of elements like in an xpath ...fig/caption/p[0] is unfortunately dangerous, as position can change due to insertion of new elements, and if two users created 'p[1]' (a second paragraph) at the same time, then there would be a collision of ids.

JGilbert-eLife commented 5 years ago

Ah, that makes sense. Thanks!

I don't imagine these ids would cause problems elsewhere but it might be something to account for when converting the XML for different endpoints e.g. PMC.

James

obuchtala commented 5 years ago

Yeah, then we can drop a lot of these ids.

obuchtala commented 5 years ago

This will be done in the 'Translation Layer'