W3C home > Mailing lists > Public > public-xmlsec-maintwg@w3.org > September 2007

Re: Fw: xpointer testcases

From: Bruce Rich <brich@us.ibm.com>
Date: Fri, 21 Sep 2007 10:48:53 -0500
To: Sean Mullan <Sean.Mullan@Sun.COM>
Cc: xmldsigtechnical <public-xmlsec-maintwg@w3.org>
Message-ID: <OF2CCBEDF8.81D76463-ON8625735D.0054AFE0-8625735D.0056DFDF@us.ibm.com>

Well said.  I agree.  From a specification perspective, xml:id is a 
mechanism for specifying ID attributes, but not a required mechanism.
For this particular testcase, none of the other mechanisms were in play 
either, so this seemed like a reasonable choice that was in harmony with 
choices for other tests.
The fact that it works well with my implementation is sheer coincidence. 
Hmm, given that the interop is next week, maybe it isn't such a 

Bruce A Rich
brich at-sign us dot ibm dot com

Sean Mullan <Sean.Mullan@Sun.COM> 
Sent by: Sean.Mullan@Sun.COM
09/21/2007 10:21 AM

Bruce Rich/Austin/IBM@IBMUS
xmldsigtechnical <public-xmlsec-maintwg@w3.org>
Re: Fw: xpointer testcases

I will make this change very soon.

However, I would like to add a stipulation that this doesn't mean that 
XML DSig implementations must use XML parsers that support xml:id. 
xml:id is a fairly recent addition and AFAIK, many parsers don't support 

I think that as long as there is some way that the application 
identifies these as ID attributes, then one can still be compliant.

Any comments on that?


Bruce Rich wrote:
> There seems to be a problem with the input.xml for the xpointer 
> testcases.  Well, at least for tests 2, 4, 5 and 6.
> The problem is that the id attributes are not specified as being in the 
> xml namespace.
> Because they are simple attributes, as in <ietf:e1 id="e1ID">, there's 
> no way that the id attribute can be known to be an ID TYPE.
> And according to http://www.w3.org/TR/xptr-framework/#shorthand
> "However, if ID typing information is not available because no DTD, 
> schema, or application-specific information is available, the pointer 
> will not identify any element."
> Thus it seems appropriate to fail to locate xpointer(id('e1ID')), for 
> example.
> The other tests that involve id do in fact call it out as xml:id, but 
> the xpointer tests either overlook that point or expect the application 
> to communicate some "application-specific information".
> I can fudge my implementation to also look for id=, but it feels wrong. 
>  One could imagine a valid document that had an elements with id="bob" 
> and xml:id="bob" like this
> <ietf:e1 id="bob">
>         <ietf:e2 xml:id="bob" />
> </ietf:e1>
> so dereferencing "bob" and getting element e1 seems wrong.
> Comments?  Presuming consensus (ok, I'm being optimistic here), would it 

> be possible to rev the input.xml for these tests before the interop?
> Bruce A Rich
> brich at-sign us dot ibm dot com
Received on Friday, 21 September 2007 15:49:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:42:41 UTC