[tei-council] xml-colon-thing

[Lou Burnard]

Hi David

I hope you'll continue giving us your views even after you cease to be a 
council member!

The idea of the P4 compatibility module presented to the TEI members 
meeting is not the point at issue here, and it's a somewhat irrelevant 
rhetorical move to conflate the two. Although it's true that I might 
advance some similar arguments in favour of producing a compatibility 
module to those I will advance in favour of the "retain id and lang" 
proposal, that doesn't mean that they're the same point, and in any case 
I don't think they're the only arguments. And I'm NOT in fact proposing 
a compatibility module at this point.

As I understand it, the argument for replacing "lang" with "xml:lang" is 
fundamentally that the latter has been recommended by W3C with a 
semantics more or less identical to that identified by the TEI for 
"lang". The argument goes on to assert that any new software likely to 
be developed will pay more attention to W3C recommendations than to TEI 
ones and that we should therefore go with the majority. I don't disagree 
with that recommendation entirely (though I seem to recall that the CE 
workgroup wasn't unanimous on this point -- Espen in particular was 
quite strongly against it): 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. 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 not all of it needs to 
be changed, and it surely can't be a bad idea to make transition to P5 
less of an obstacle if we can do so.

It's all very well to say we'll go on supporting P4 and people can stick 
with that if they like, but there are a lot of good things in P5 that 
will never be retrofitted to P4! The new module system, the new ODDs, 
the improvements in the core modules, the new modules like MS and gaiji 
-- these are things we want people to start using now, and which the TEI 
community wants to take up. 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. 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.

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? In which case I'd also like to put on the 
agenda for the discussion the possibly heretical suggestion that we 
might choose to *retain* target="foo" (for the benefit of legacy systems 
that understand ID/IDREF) as an alternative for  url="#foo" (or whatever 
its name is to be). Note however that I'm not suggesting that we should 
also attempt to retain the whole baggage of the TEI extended pointer 
syntax, <xptr> etc.  -- just that we keep the ability to use the 
shedloads of existing tools which use target and id in anticipation of 
the great dawn of xlink-aware software that is just around the 
corner.... (still)

Lou


David G. Durand wrote:
> I'm assuming that I'm still a council member until the end of the 
> calendar year...
> 
> I don't like this idea at all, nor the one (apparently) discussed at the 
> TEI members' meeting. As roughly described to me second-hand, it seems 
> to have been a proposal that we should rename elements and attributes 
> changed as to function in P5 so that it will be easier to extend P4 by 
> the re-addition of p4 elements that have been replaced by newer 
> functions/notations in P5.
> 
> We shouldn't (and can't under our own rules) prevent people from using 
> any tagging practices we want, but I don't think we should "ease 
> migration" in a way that allows existing P4 documents to become P5 
> documents without updating the markup. There's no shame at staying with 
> P4 if that suits one's needs. The decision to allow non-compatible 
> changes is a good one in that it enables things to be cleaned up without 
> constraint as to compatibility, and that's a good thing, I think. 
> Renaming things just to make using the old names easier is bad because 
> it makes the new names less useful, and the whole issue of support 
> _more_ complicated.
> 
> In the XML committee we had a slogan of not being "gratuitously 
> incompatible" with SGML, and in that situation the need for backward 
> compatibility seemed much stronger. I'd also note that XML itself could 
> have been more incompatible without serious problems, as things turned out.
> 
> I don't really see how it helps in moving legacy data: for xml:id, you 
> have to add a '#'. For xml:lang you have to make up a table converting 
> whatever strings you used in your TEI "lang" to the standard strings as 
> defined by the ISO and W3C.
> 
> P5 is going to have to go through a process of acceptance and tool 
> building (as previous versions have) and the center of gravity will 
> slowly shift to the newer version, as people so the work of conversion.
> 
> People will have to compare the effort of touching old data and shifting 
> their tool environment, versus staying with the old markup and foregoing 
> the improvements of P5, or the duplicated effort if they maintain data 
> in both formats and thus have to deal with two separate tool chains. 
> Granted this can be a hard decision to make, and will certainly involve 
> some extra work if one wants to use new P5 features or tools, but it 
> seems to me that that's the reality of this kind of work.
> 
> I'd be more sympathetic if I thought that people _had_ to move to the 
> new world, but they can linger on the margins of P4 as long as they 
> want. They can even add stuff from P5 into P4 if they want to.
> 
> If we're to make a break (and we've decided that long ago), I say that 
> it should be a clean break, with no guilty half-measures or apologies.
> 
>   -- David
> 
> On Nov 11, 2004, at 12:15 PM, Lou Burnard wrote:
> 
>> The Character set workgroup has proposed and the Council has (I think) 
>> accepted that  the global lang attribute should be replaced by a 
>> global xml:lang attribute; likewise the Standoff WG has proposed and 
>> the Council is (I think) still ruminating about the notion that the 
>> global "id" attribute should be replaced by a global xml:id attribute.
>>
>> Pondering how to actually implement these proposals in P5 without 
>> causing too much havoc, I have reached the conclusion that it would be 
>> both feasible and advisable to make the transition in a rather more 
>> cautious way. I am proposing to add xml:lang as an *alternative* to 
>> lang in the definition for  tei.global.attributes rather than as a 
>> replacement for it.  (And similarly xml:lang). By "alternative" here I 
>> mean that a given element can specify one or the other but not both 
>> (supplying both would in any case be impossible since both have ID 
>> declared values). The current ODD syntax already supports this -- we 
>> added it art Christian's suggestion during the Paris Meta meeting -- 
>> and indeed uses it for similar backwards- compatibility-reasons in the 
>> definition for <figure> I think. The schemas generated do exactly the 
>> same thing: the DTD generated may need some further hand adjustment.
>>
>> I think it is a good idea to hedge our bets about the take up of W3C 
>> recommendations in this way, and it will definitely make the job of 
>> moving legacy data to P5 a whole lot easier. Not least for us!
>>
>> Comments?
>>
>> Lou
>>
>> _______________________________________________
>> tei-council mailing list
>> tei-council at lists.village.Virginia.EDU
>> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>>
>>
> 
> David G. Durand
> Director, Electronic Publishing Services
> Ingenta Inc.
> 111R Chestnut St.
> Providence, RI  02903 USA
> 
> T: +1 401-331-2014 x111
> T: +1 401-935-5317 Mobile
> E: david.durand at ingenta.com
> 
> _______________________________________________
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>