Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XOM 1.1 proposal: xml:id

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: Elliotte Harold <elharo AT metalab.unc.edu>
  • To: John Cowan <jcowan AT reutershealth.com>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] XOM 1.1 proposal: xml:id
  • Date: Thu, 20 Jan 2005 09:06:40 -0500

John Cowan wrote:

In any case, though, every xml:id attribute gets leading and trailing
whitespace removed, internal whitespace collapsed to a single space,
and its type set to ID.

I just looked this up, and it's a little trickier than that. It is possible for an ID-type attribute to have uncollapsed, internal whitespace if that whitespace consists of tabs, carriage returns, and line feeds inserted by numeric character references. This would be an xml:id error because the resulting value would not be an NCName, but it might not be a well-formedness error.


I'm not clear why XPath and XInclude are specially relevant; I'd think
it was Attribute.setType and Attribute.setValue that need to change in
order to make this work automatically. The xml:id recommendation
does not require the uniqueness check (it's a SHOULD not a MUST),
so that check could be omitted in XOM or provided externally.

Both XPath and XInclude (more properly XPointer) have functionality that finds IDs. Possibly I could have them recognize xml:id without necessarily adding anything special about xml:id to the core of XOM. However, you're right. If I do add it to the core, then XPath and XPointer will probably just work without any extra effort there.

--
Elliotte Rusty Harold elharo AT metalab.unc.edu
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim




Archive powered by MHonArc 2.6.24.

Top of Page