xpath/xpointer expressions in ref/@target

[ttasovac]

We say that ref/@target could have the following values:

• # + xml:id: reference to element by xml:id inside current document
• URI reference
• xpath/xpointer expressions, using TEI xpointer schemes (http://www.tei-c.org/release/doc/tei-p5-doc/en/html/SA.html#SATS)

• null: there is no concrete reference

I would like to propose that we get rid of xpath/xpointer expressions. I think TEI Lex-0 doesn't have to cover everything that TEI does. I need a second opinion and/or good examples/arguments for why we would want to point to things this way.

[ttasovac]

Ok, (Laurent and I discusing) We are not going to do null, but rather allow no attribute target.

The text should say: we use URI reference as per TEI, but more specifically we impose that intradictionary references are based on explicit xml:id references.

[ttasovac]

Dear @laurentromary,

I changed the description of ref/@targetvalues in the narrative section, as we discussed the other day. However, this still feels incomplete to me. I think we should:

• further constrain URIs to allow only http or https prefixes. We shouldn't allow URIs that start with ftp, mailto or file for instance.
• enforce that local references (to the same dictionary) are in the shape of #+xml:id (and, perhaps, offer a schematron rule for checking all links — we use those regulary)
• enforce that no xpointers are used (i.e. #xpath(), #range() etc. should not be allowed.

What do you think?

[laurentromary]

I would really not hack the anyURI type in our context since the syntax covers all our needs (see [https://en.wikipedia.org/wiki/Uniform_Resource_Identifier#Examples_2]) and we mainly need to be explicit in our text about what we recommend.

[xlhrld]

@ttasovac wrt the proposed protocol restrictions: While some protocols like ftp – even though rarely used if used at all – would at least work in principle, things like file are actually used rather often. They just happen to be left implicit in many cases. People use file whenever they have their files stored locally and rely on references to other files. I've even seen hard-coded file references in TEI sources more than once, actually. email is probably ruled out for practical reasons anyway – nobody will use it even though its technically legal. (I can still imagine some weird »upon request« reference scheme based on email …) In short, I would not forbid things that work in principle and that are rather technical implementation details – and in a way outside the scope of the TEI.

Another general point to consider: It would seem arbitrary to restrict the anyURI datatype for ref/@target when we do not touch other anyURI based attribute values (e. g. everything in att.global.linking).

[ttasovac]

Ok. I was thinking it would be more useful to restrict for the sake of post-processing etc., but we shouldn't prevent people from using TEI Lex-0 also in their own work (not just as a baseline encoding for comparison) so in that sense it wouldn't make sense to impose additional restrictions.