[tei-council] xml-colon-thing

[Syd Bauman]

> ... my suggestion is not that we should try to keep lang to the
> exclusion of xml:lang. Rather it is that we should allow for a
> transitional period in which existing TEI software which does
> understand and use "lang" in exactly the same way that software
> yet to be constructed will presumably use "xml:lang" should
> continue to be usable in the new regime.

OK, I'll bite. What software do you have in mind? Could this
software be used on a P5 file at all?

I'm thinking that if there does exist software that intelligently
makes use of the lang= of TEI P4 files, that software is going to
need to be reworked quite a lot to process a P5 file in the first
place. Is there really an enormous advantage to delaying changing
the part of the code that handles lang= so that at reads "xml:lang"
instead of "lang" and doesn't depend on their being a corresponding
<language>?


> It's more about software than data: as you correctly point out,
> legacy data may need to be changed anyway if it doesn't use the
> right language identifiers. 

But legacy software needs to be changed anyway, too.


> ... it surely can't be a bad idea to make transition to P5 less
> of an obstacle if we can do so.

That depends entirely on the cost of the construct (for lack of a
better word) being implemented to make transition less of an
obstacle. If (as in this case) the cost of the construct that would
make transition easier also makes P5 a weaker specification, then
yes, it may be a bad idea.


> So I think we ought to try at least a little to be more
> accomodating, where we can do so without too much effort or
> confusion.

I think presenting users with "you can use either lang= or xml:lang="
and "either id= or xml:id=" is, in fact, adding confusion. The
question is whether or not the extra ease in migration is worth the
added confusion. Personally, I don't think so, but I'm willing to be
convinced.


> My suggestion is that allowing for the old names to subsist, as
> alternates for the new ones, buys us a lot in terms of lowering
> the entry price, at virtually no additional cost in maintaining
> duplicate tool chains. OK, new tools have to allow for either
> lang or xml:lang and have to process them identically. But that's
> it.

While I guess it does lower the entry price, seems like a pretty
significant cost to me.


> The case with id and xml:id seems more or less the same to me.
> The point you make about having to change the values of this
> attribute in legacy data seems mistaken: surely the new version
> of id="foo" is xml:id="foo", not xml:id="#foo"? Where data has to
> change is in the value of the "target" attribute surely?

Absolutely, it's the IDREF and IDREFS attribute values that need to
be changed to have the preceding "#".