RE: Test Case with xml-dsig

Hi Norman,

The thing you're describing, to add xml:id as a channel
for reporting IDness, is exactly what I was referring to
when I said that you aren't changing the interface but
you are changing the data model.

The problem with justifying the approach using Appendix B 
of XPath is that the appendix is non-normative.  The 
normative definition of the data model appears in 
Section 5.  The intent of Appendix B was to describe
how to connect the xpath data model to a related work
*in 1999*.  That the infoset can *now* be derived from 
a richer underlying set of resources is interesting, 
but it does not obligate *any* consumer of XPath 1.0
to support the result.

Don't get me wrong. It can be useful in some applications
where interoperability is not required to join up these
different recommendations.  It is possible, as you've
observed, because no change to the XPath interface is
required, only low-level modifications and augmentations.

But XML Signatures requires interoperable C14N, and 
augmentations to the normative definition of the XPath
data model do not achieve that result.  All that would
happen is that people would stop trusting the XML
signatures, which presumably they adopt precisely because
of interoperability concerns.

Best regards,
John Boyer, Ph.D.
Senior Product Architect and Research Scientist
PureEdge Solutions Inc.


-----Original Message-----
From: Norman Walsh [mailto:Norman.Walsh@Sun.COM]
Sent: Monday, February 07, 2005 1:59 PM
To: John Boyer
Cc: Joseph Reagle; Gabe Wachob; public-xml-id@w3.org;
w3c-ietf-xmldsig@w3.org
Subject: Re: Test Case with xml-dsig


/ John Boyer <JBoyer@PureEdge.com> was heard to say:
|>That's not strictly true. It's possible to introduce xml:id
|>processing into the XML stack at or just after the parsing process,
|>producing an XPath 1.0 data model in which all attributes named xml:id
|>are of type ID irrespective of whether or not a DTD or schema is used.
|>In that case also, XPath supports xml:id.
|
| Yikes, I would argue that introduing xml:id into the stack amounts to
| not producing an XPath 1.0 conformant data model.  XPath 1.0 does not
| support xml:id, so introducing it would result in a c14n that does not 
| conform to the recommendation.  The addition of xml:id creates something 
| that requires no interface modifications to query the resulting infoset, 
| but an xpath 1.0 data model it isn't.  The xpath 1.0 data model states
| that identified elements are identified by attributes declared to be
| of type ID ** in the DTD **.

I see your point and certainly I think it would be unwise to imagine
that inserting an xml:id processor at a low level in your stack would
have no impact on your applications, especially applications that
involve security or digital signatures.

But I think there's room in the XPath spec to justify the addition of
such a processor. In particular, Appendix B says:

  The unique ID of the element node comes from the children property
  of the attribute information item in the attributes property that
  has an attribute type property equal to ID.

and one of the mechanisms for an xml:id processor to report the IDness
of xml:id attributes to the application that calls it is by changing
attribute type property of the xml:id attribute in the Infoset.

One of my personal motivations for xml:id was to allow documents that
don't have any DTD or schema to make use of the id() function in
XPath. (In particular to avoid the sorts of problems I had in the
early days of the DocBook stylesheets when I was using the id()
function before support for keys was widespread.)

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.

Received on Monday, 7 February 2005 23:11:21 UTC