norman.walsh.name: Comments on /2005/09/14/xmlidhttp://norman.walsh.name/2005/09/14/xmlid/comments.atom2012-02-13T06:29:52.361909ZComment 1 on /2005/09/14/xmlidhttp://norman.walsh.name/2010/09/25/oauth#comment00012005-09-15T10:09:57Z2005-09-15T10:09:57ZOleg Tkachenkoda39a3ee5e6b4b0d3255bfef95601890afd80709

1b/2b sound reasonable to me.

Comment 2 on /2005/09/14/xmlidhttp://norman.walsh.name/2010/09/25/oauth#comment00022005-09-15T10:29:58Z2005-09-15T10:29:58ZRasmus Kajda39a3ee5e6b4b0d3255bfef95601890afd80709

Yes, 1b/2b seems natural. And xml:id should of course not be inherited. But how should xml:somethingnew be handled? Should there be a new version of the C14N specification each time a new attribute in the xml namespace is defined?

(This seems to be another argument for an inclusive XML specification, where all attributes in the xml namespace, C14N, and some other stuff, is defined in the same specification.)

Comment 3 on /2005/09/14/xmlidhttp://norman.walsh.name/2010/09/25/oauth#comment00032005-09-15T17:41:56Z2005-09-15T17:41:56ZRich Salzda39a3ee5e6b4b0d3255bfef95601890afd80709

What does "fixup" mean -- can you provide an example or two? I am concerned about adding URL/URI processing to a canonicalizer. I note that no other imported "xml:" values are modified or otherwise fixed-up.

Since xml:id will clearly not be imported, there's precedent to not import xml:base. It seems that the cleanest way to update C14N is to remove the "magic import" clause for attributes not already mentioned (space and lang).

How often is C14N used by itself, as opposed to feeding it into a digest mechanism? How often is C14N used on an XML subset, by itself, as opposed to feeding it into a digest mechanism? My guess is not very, and rarely. In that case, "fixing up" attribute values is of no use.

Comment 4 on /2005/09/14/xmlidhttp://norman.walsh.name/2010/09/25/oauth#comment00042005-09-16T14:45:41Z2005-09-16T14:45:41ZDamian Cugleyda39a3ee5e6b4b0d3255bfef95601890afd80709

I think the issue with xml:base is something like this:

      <foo xml:base="http://example.com/">
  <bar xml:base="shoes/">
    <baz href="socks"/>
  </bar>
</foo>

If I pull out the baz element, simple inheritance adds attribute xml:base="shoes/", which is incomplete. The effective XML-base value for the baz element is http://example.com/shoes/.

I suspect this is a general problem with the xml-namespace attributes: they are often used to annotate a subtree of the XML document with some new trait whose inheritance rules the canonicalization recommendation cannot be expected to anticipate. Tricky!

Comment 5 on /2005/09/14/xmlidhttp://norman.walsh.name/2010/09/25/oauth#comment00052005-09-26T16:28:34Z2005-09-26T16:28:34ZStuart Williamsda39a3ee5e6b4b0d3255bfef95601890afd80709

I think that the may be a few different patterns that could be applied to the canonicalisation of xml: namespaced attributes. Inherited or not is a pattern that's mentioned here. With respect to URI values there's also whether or not they should be 'fixed' up.

A future rev to C14N could call out various attribut 'canonicalisation' patterns, grandfather existing attributes by stating which characteristics apply to which xml: attributes. It could also place an obligation on those creating new names in the xml: namespace to state which canonicalisation pattern applies to the new attribute. That at least avoids the C14N spec. maintenance problem (until a new pattern is required). However, it does not avoid the need to maintain implementations - particularly if a default pattern is stated for the treatment of 'unknown' attributes - and the new attribute requires non-default treatment.

BTW: it also seems to me that describing the scope of the influence of a given attribute might be something that a schema could usefully do.