Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] xml:* attributes in Canonicalizer

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: John Cowan <jcowan AT reutershealth.com>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest AT lists.ibiblio.org
  • Subject: Re: [XOM-interest] xml:* attributes in Canonicalizer
  • Date: Wed, 9 Feb 2005 17:15:41 -0500

Elliotte Harold scripsit:

> It could well be a bug. This is all very new and I'm trying to figure
> it out as I go. There are definitely some surprises here. I'll try to
> see if I can cook up a test case to see if this is really happening.

The concept is that you should grab an xml:* attribute from your nearest
ancestor (if you don't have one yourself) only if you are being canonicalized
but your parent node is not. In that way,

<a xml:space="preserve"><b><c/></b></a>

when canonicalized using an XPath that excludes the a element, will come out

<b xml:space="preserve"><c/></b>

thus maintaining the semantics that b and c have whitespace preserved.

Of course, the *real* intent was to do this only for xml:lang and xml:space.
Doing it for xml:base can cause bogus results:

<a xml:base="foo/bar"><b xml:base="baz"><c/></b></a>

when only c is selected will canonicalize as:

<c xml:base="baz"/>

instead of the logically correct

<c xml:base="foo/baz"/>

because xml:base attributes with relative URIs are cumulative with their
parents rather than overriding them. (I may have the details wrong, but
the principle is right.)

Unfortunately, we're probably stuck with this for Canonical XML 1.0, even if
we can get it fixed in Canonical XML 1.1.

--
Winter: MIT, John Cowan
Keio, INRIA, jcowan AT reutershealth.com
Issue lots of Drafts. http://www.ccil.org/~cowan
So much more to understand! http://www.reutershealth.com
Might simplicity return? (A "tanka", or extended haiku)




Archive powered by MHonArc 2.6.24.

Top of Page