RE: Test Case with xml-dsig

Hi Norman,

>No offense was intended, please accept my apologies for not expressing
>that more carefully.

Thanks; none taken.  There's just a great propensity for people to read
these public lists and not be aware of the history and go away saying that
the W3C had some oversight, etc. etc.

>It's risky for specifications to make assumptions about how other
>specifications will evolve. It's an unfortunate fact that xml:id does
>not share the "inheritable" behavior of the previous attributes in the
>xml: namespace.

Agreed, we technically shouldn't have assumed this, although it was more
a case of believing that this was just how things worked because the 
only xml namespace attributes that will ever affect the given c14n algorithm
are the ones that are predefined.

| The only way to get these applications to support xml:id
| is to declare this attribute as being of type ID in the DTD.

>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 **.

Cheers,
John Boyer

Received on Monday, 7 February 2005 21:43:59 UTC