Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: determining ID-ness in XML
 [Trying to keep this one on both xml-dev & ietf-xml-mime] At 08:40 AM 29/10/01 -0600, Paul Grosso wrote: >Here are some options (all discussed before): >1. use the internal subset to declare IDs #1 is minimal-impact. Can it be sold? I.e., if you want the "name" attr to be an ID, then you need the following at the top of the file with a line for each element type that "name" can appear on: <!DOCTYPE rootType [ <!ATTLIST element1 name ID #IMPLIED> <!ATTLIST element2 name ID #IMPLIED> ... etc... ]> I'm not sure it's going to be easy to get the community to buy into this. >2. use a PI to declare IDs Yecch. Barf. Blecch. Feh. Oh, this is supposed to be a technical discussion. >3. put an xml:id attribute into the xml namespace >Are there others? What are the pros and cons? The advantage of xml:id is that the "xml" namespace doesn't need to be declared per the namespace rec. You could have another namespace declared like so <rootEl xmlns:xmlid="http://www.w3.org/2001/xmlid/"> <foo xmlid:a="label1"> <bar xmlid:b="label2"> </rootEl> where the semantic is that no two attributes in this namespace can have the same value in the same doc, and you *might* even be able to get away without requiring a namespace declaration, since those beginning in "xml" are reserved per the namespace spec, presumably for exactly this kind of thing. Note that this is not mutually exclusive with having xml:id. My own opinion is that this is unnecessary complexity - just use xml:id... the advantage of having a new namespace, that you get to choose your own names for IDs, is kind of obviated by the fact that attribute prefixes don't default so you're always going to have that ugly xmlid: in front, so why not just bite the bullet and use xml:id? And as I said, I think it's still not too late to take this kind of a step. >In short, what's the right answer? Procedurally? A new W3C note leading to a tiny 2-page REC, I'd say. Easier than re-opening either the XML or Namespace RECs. The namespace approach(es) have the huge advantage of making an important semantic aspect of XML documents self- documenting. In fact, on the Web, I might argue that the lack of a clear self-documenting way of establishing the semantics of '#whatever' in a URI reference is a nearly fatal architectural flaw. Hm.... the one problem is that if you're dealing with XHTML or SVG, which already *have* ID elements defined normatively as part of the language, you have to say what happens when there's a conflict, e.g. suppose you have <html:div id="p3"> ... </div> <html:div xml:id="p3"> ... </div> Is this an error, or does the built-in id "win", or do we leave it up to language designers to define how to coexist with xml:id? -Tim 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
