Should TEI attributes be in the TEI namespace?

[ebeshero]

When we customize the TEI to introduce our own attributes, we must do so in the project's namespace.
But the TEI doesn't apply this logic to its own attributes, which are in no namespace.

If in P6, an attribute may be expressed as an element, and we continue to apply the TEI namespace, shouldn't the namespace apply then to attributes as well as elements?

[martindholmes]

@ebeshero I think you might be over-generalizing the discussion we had about concepts being realizable as elements or attributes. My recollection was that we wanted to make it possible for any given concept to be instantiated in a schema as an element or an attribute, depending on what was more appropriate -- so the fact that it was an "element" or an "attribute" was not part of its definition as a concept -- but not that we wanted to arbitrarily realize all concepts as elements and attributes in RNG schemas irrespective of whether that was an effective or appropriate form for them to take in XML. As the TEI, we would probable make a decision on each case, and while there would be cases (as there are now in P5) where parallel elements and attributes may exist in the same schema, those would probably be exceptional cases.

My instinctive response to the question on this ticket is actually no, but mostly for the purely practical reason that all the required ns prefixes would really clutter up our encoding without adding any benefit that I can see.

[ebeshero]

Hold this thought:
'My recollection was that we wanted to make it possible for any given concept to be instantiated in a schema as an element or an attribute, depending on what was more appropriate -- so the fact that it was an "element" or an "attribute" was not part of its definition as a concept'.

Yes, and as I recall, we discussed that this decision in P6 of whether to generate a concept in element or attribute form will be up to the customizer. Distinct blueprints might implement this differently, since conceptually either expression should remain possible.

[ebeshero]

Blueprint modeling surely is not "arbitrary" but rather carefully considered. One blueprint's element may well be another's attribute. And to be sure some concepts will be better expressed in elements, but this too will be deliberate, not arbitrary.

I had thought that implementing elements and attributes in the same default TEI namespace would simplify matters and perhaps not require prefixes. But yes of course they're required and it's an XML limitation that unprefixed attributes lack a namespace.

This raises questions for P6 and the capacity to express a TEI concept as an element or an attribute. I don't think we agreed that TEI would unilaterally decide that for anyone in P6, at least not in any single model, but rather that we provide ways to be maximally expressive in content modeling. (And one of those models should express P5, among others.)

If that maximal expressiveness is what we want, we should think about namespaces: Why should a TEI concept drop the TEI namespace if expressed in attribute form? Surely not just to avoid a little prefix?

[ebeshero]

Substantially updated previous comment.

[martindholmes]

@ebeshero Why would we not simply assume, and articulate, that any attribute in the empty namespace which is on an element in the TEI namespace is assumed to be a TEI attribute? That's surely the assumption we make right now, whether explicitly or not.

[hcayless]

This would also raise the question of how to deal with the xml:* attributes, unless you plan to replace them with TEI analogs. I fear this could get quite complicated.

[bansp]

Chiming in without the full context, so please bear with me.

• Thanks for giving a thought, in discussions about P6, to the split between ordering concepts in a model on the one hand, and serialising them according to sometimes purely practical needs on the other -- it is good to see that serialising a concept as an element or an attribute is something that is not treated as accidental.
• Elisa's insticts to keep the serialised vocabulary separate and identifiable are excellent from the modelling-project-management point of view, but I also understand Martin's instinct: if an overarching principle can be invoked for some domain, and if there is a tradition coupled with known shortcomings of XML, why not keep things simple and say that "any attribute in the empty namespace which is on an element in the TEI namespace is assumed to be a TEI attribute".
• Except that, it seems to me, there is a hidden 'imperial' assumption in Martin's approach, and again I can quote Martin saying that "that's surely the assumption we make right now, whether explicitly or not" -- most of us are used to the view where foreign markup (whether imported from another format or being a result of 'direct' customisation of the TEI) is scattered across solid TEI texture: just like we use xml: attributes all around (a nod to Hugh) and used to use rng: attributes across ODDs, stuff that gets sprinkled across the canvass gets appropriately identified.
  • So, to be sure, I am not pointing a finger at Martin. I think most of us dealing with the TEI for a long time entertain that 'imperial approach' by default.
• But we can turn this around, admit that re-use and incorporation can go both ways (and that may be on the increase, though I don't have any numbers), and imagine that selected pieces of the TEI are incorporated into a canvass that is defined by a non-TEI general format that is nevertheless TEI-like in making the 'imperial' assumption that "if it's in my yard, then it has my dust on it. so no need for any extra branding". Preparing for such use cases, it would be good to make sure to keep the vocabularies distinct.
• Which pieces? One piece that comes to mind is free-standing TEI headers that do not have to be free-standing, but can get aggregated or incorporated -- as useful, well-defined metadata-carrying boxes -- inside a larger, non-TEI format. Another possible piece I can think about is (you guessed it :-)) att.linguistic, used as a class inside non-TEI markup -- and here we are talking attributes alone. And I'm sure other potential TEI intrusions inside different markup could be found.

One could suggest a switch for P6: we use the 'imperial' approach for easy cases, and switch to the 'archipelago' approach elsewhere -- but that, in turn, seems tainted with the assumpion that P6 is going to target XML, with XML-specific namespace issues (and other restrictions that are peculiar to XML). Maaaybe P6 should rather not assume XML as the default serialisation format, and be prepared for the 'archipelago' mode up front, whereby "my toys always bear my stickers", whether in my yard or some other yard.

[jamescummings]

I'm very used to the idea that any attribute on a tei:* element in the empty (default, null) namespace is considered a TEI one. I think there are other standards which do this as well. Yes, so we specify xml: rng: svg: etc. when using other attributes as a consequence. I think the encouragement should be to assume that things are in the TEI ecosystem unless otherwise stated (though that may go against some of the mission ideals for P6, and that might be enough to change this). I would note that lots of people have a problem with namespaces anyway, and so problematising it by enforcing a namespace prefix for each and every attribute seems overkill to me. If someone was adopting TEI-specific attributes onto non-TEI elements, then yes, I would expect them to put those in the TEI namespace and prefix tei: if they themselves use the default/null namespace for their own attributes. (And probably even if they don't.) But, I think the compatibility layer for those just using TEI (and xml attributes) should be to maintain them in the default/null namespace.

Just thinking aloud after a long day of travelling, so maybe I'm not being coherent or maybe missing obvious things!

[ebeshero]

Just a quick thanks to @bansp for fleshing out the "imperial" vs. "archipelago" perspectives on TEI namespacing, which helps bring clarity to the issue of what the namespacing means. Linguistics provides an excellent context, as well as the mapping of TEI personographies and standoff to RDF and graphs.

We do want to faciliate clean mapping of TEI from XML to alternative serializations, where the concept represented by an attribute and its value(s) can be expressed in other ways, but clearly defined as either TEI or custom namespaces.

[bansp]

Like I said, I'm speaking without the full context of P6-related discussions, so please bear that in mind throughout.
And from that limited perspective, I would point out that James speaks from a heavily XML-centric position, whereas (as Elisa indicates) P6 may wish to look beyond XML, and treat it not as the sole target, but rather as well-known and well-tested legacy, to be recognised and tended to, but which doesn't fill the entire the horizon of everyday applications.

( I am not saying that something better than XML is on the horizon, but I'm saying that, all too often, "worse is better" -- and we see that in language-resource encoding as well, and all around the place now. And P6 may want to cater to all kinds.)