/ John Boyer <JBoyer@PureEdge.com> was heard to say:
| C14N isn't "just plain broken" with respect to xml:id.
|
| C14N was produced years before xml:id and therefore
| "does not support" xml:id.
No offense was intended, please accept my apologies for not expressing
that more carefully.
C14N was written with the assumption that all attributes in the xml:
namespace were inherited by their descendants. When C14N was written,
the only examples of attributes in the xml: namespace were xml:lang,
xml:space, and xml:base, all of which behave in this way.
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.
| Moreover, it cannot be modified to do so without also
| upgrading XPath, which also "does not support" xml:id.
As you note below, if a DTD or schema defines the xml:id attribute as
being an ID, then it's supported direclty in XPath.
| 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.
| I would very much love to see a new C14N algorithm
| (which would naturally have a new algorithm URI),
Indeed.
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.