RE: Options for dealing with IDs

Tim, Chris, Norm,

At the risk of entangling this topic with that of linking in XML I'm
wondering whether the solution to the questions raised in this is entangled
with the solution to the linking in XML.

This thread asks the question "How do I recognise IDs in XML documents?"
which looks a bit like the linking question of "How do I recognise links in
XML documents?". There are common concerns about not having to require
validation; about having an approach that can be adopted by existing XML
languages; and about having an approach that 'works' in mixed-language
cases. This seems to be about the eXtsensible in XML - elementist/attibutist
viewpoints and possibly the choice of a namespace that is implicitly
declared (xml:).

(Optimistically) I'd hope that *IF* we were able to reach a principled
resolution to the linking question, then by and large the same principles
would apply to the ID question and the right answer would then be obvious. I
don't think that it works the other way round, because links are more
complex structures than IDs (actuation, transition effects, travesals,
roles, arcroles...). 

The xml:id design seems very coherent with XLink's xlink:href approach -
recognition based on relatively direct recognition of atttribute names. 

The element scoped xml:idAttr option introduces a level of attribute
remapping which in somes sense is evocative of HLink. As has been shown
elsewhere on this thread [1] xml:idAttrs becomes a bit cumbersome in mixed
language contexts where there is a lot of switching of id attribute names,
equally in legacy languages cases if the name of the id element varies
widely with host element name. This might motivate a means for stand-off
mark-up to remove clutter from the instance document - and for some that
would no doubt be going too far.

So... standing back a little from the particulars of IDs and hrefs and
IDREFs, I'm wondering if there are some princples that we could identify
related to extensibility and mixed languages in XML. Chris has described
this as a problem of conflating decoration with validation [2]. Maybe that
is the problem to attack and the solution to IDs and XML Linking - and then
we might have made a little headway on mixedNamespaceMeaning-13.

Just thinking aloud...

Regards

Stuart
--
[1] http://www.w3.org/mid/9828748798.20030110171719@jenitennison.com
[2] http://www.w3.org/mid/9162008812.20030107192704@w3.org


> -----Original Message-----
> From: Tim Bray [mailto:tbray@textuality.com]
> Sent: 11 January 2003 22:00
> To: Chris Lilley
> Cc: www-tag@w3.org; Norman Walsh
> Subject: Re: Options for dealing with IDs
> 
> 
> 
> Chris Lilley wrote:
> 
> > This is the current mess. This is 7) Muddle along. This is "lets
> > insert some user agent sniffing on the server so that we 
> can get a bit
> > more interoperability". And this is, to be harsh but fair, the utter
> > shambles that Tim Bray proposes we get comfy living in.
> 
> C'mon Chris, stop holding back, tell us what you *really* 
> think.  OK, I 
> admit to already being comfy with the way things are; furthermore, I 
> have never prior to this discussion seen a sustained burst of 
> the energy 
> from the community demanding change in this area.  I think 
> everyone is 
> probably prepared to be convinced that we have a problem here 
> if enough 
> people pipe up about it.
> 
> So.... let's think about this in a little greater detail.  Suppose we 
> were to adopt the "xml:id" solution - I examine that one because it's 
> probably the simplest, involving the fewest corner cases.  I'm not 
> trying to prove anything, just thinking through this in public.
> 
> XML 1.* says that when a DTD declares that an attribute is of 
> type ID, 
> then it is a validity error if
> 
> (a) it is syntactically anything but a NAME, and
> (b) there are two attributes so declared in the same document 
> with the 
> same value
> (c) there are two attributes so declared which can be attached to the 
> same element (not an issue with xml:id, but with xml:idAttr)
> 
> (BTW, I'd think it would be advantageous if we could junk 
> conditions (a) 
> and (c) as a side-effect of our work here).
> 
> What are the other defined semantics of ID?, XPointer drafts suggest 
> that an xpointer consisting only of a NAME means "the element which 
> contains an ID attribute whose value is that NAME".
> 
> Then there's the DOM call, but I suspect that the definitions 
> there are 
> sufficiently fuzzy so as to make the impact of changes low.  
> Are there 
> any others out there?
> 
> So one way we could write this is to say that an XML 
> processor should, 
> when it encounters xml:id= on element any:thing, pretend that 
> it saw a 
> DTD declaration along the lines of
> 
> <!ATTLIST any:thing id ID #IMPLIED>
> 
> which would require a validity error if either (a)-(c) above 
> do not hold.
> 
> So this would require some basic redefinition work on XML 1.*; let's 
> optimistically assume XPointer would get the semantics by 
> reference, and 
> the DOM would sort things out.
> 
> It also ties the semantics of xml:id very close to the ID notion from 
> DTDs as expressed in (a)-(c) above.
> 
> Seems off the top of my head that it might be smarter to invent a new 
> thing with a new name, call it an "address attribute" or AA 
> for short. 
> An AA would have the semantics that
> 
> (aa1) it can be applied to any element
> (aa2) to function most effectively, the value of an AA SHOULD 
> be unique 
> in the containing document.
> 
> I don't see any need to drag validation or NAME-syntax issues in.
> 
> In fact, for the purposes of XPath and XPointer and the DOM, 
> you don't 
> *really* need to require uniqueness, you just say that 
> foo#bar matches 
> the first instance of an AA with value "bar" in the document.  Worked 
> just fine for NAME= in legacy HTML for years.
> 
> And on reflection, it seems like xml:id would be kind of ineffectual, 
> since it wouldn't help all the languages already out there 
> who would (if 
> Chris is right) like a standardized way to tell a processor 
> that id is 
> an ID.  So you probably have to go all the way to xml:addAttrs=... or 
> maybe xml:AAattrs; oh joy, another declaration mechanism.  More Qname 
> cruft.  Bah.  -Tim
> 
>

Received on Monday, 13 January 2003 12:40:36 UTC