- From: Sean Mullan <Sean.Mullan@Sun.COM>
- Date: Fri, 21 Sep 2007 11:21:22 -0400
- To: Bruce Rich <brich@us.ibm.com>
- Cc: xmldsigtechnical <public-xmlsec-maintwg@w3.org>
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 it. 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? --Sean 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:21:43 UTC