- 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