RE: Last Call

Hi Doug,
  John,

  Thank you for the opportunity to comment on this updated draft.  My
previous suggestions seem to have been addressed quite well in this version.
I have a few new questions:
    a.. In section 2.1 (with regard to the third paragraph), please confirm
that comments in the internal subset are always discarded, regardless of any
Boolean flag controlling overall handling of comment nodes.  Words to this
effect may be a worthwhile addition to this section.
    b..
    c.. <john>They are, by virtue of eliminating the DTD as listed in
section 1.1.  I will add a parenthetic statement to clarify this in Section
2.1 as requested.</john>
    a..
    b.. In the bullets near the end of section 2.2, the term "sorted
lexicographically" is ambiguous.  Do you mean that namespace and attribute
nodes are output in order from least to greatest lexicographically?  Or,
greatest to least?  (The later examples show the first.)
  <john>Lexicographically literally means 'dictionary order', which is
ascending in the chosen alphabet (UTF-8 in our case), so I did not think
there was ambiguity here.</john>

  In the same bullets, why are attribute nodes output using an order derived
from the namespace URI values?  Such a requirement seems more appropriate if
the Canonical XML recommendation includes namespace re-writing rules.  As
things are now, why not sort the attributes using the namespace prefix as
the primary key?

  <john>They are sorted by namespace URI because this follows more closely
the intent of XML Names, which is to identify namespaces by URI+localname,
not by prefix+localname.  Thus, the effect of the sort is to group together
all attributes that are in the same namespace.  Though not a requirement for
producing an unambiguous canonical form, it is preferrable, particularly if
one factors in the optics of *appearing* to violate the intent of XML names
by sorting with prefixes, even if one is not technically violating the
intent.</john>
    a.. In the last two bullets in section 2.3, the addition of leading #xA
characters according to the given rules will add such characters in most
contexts.  Comments and processing instructions are likely to occur within
the document and will thus have a greater document order than the document
element.  I believe you meant to limit this addition to processing
instructions and comment nodes with a greater document order than the end of
the document element.
  <john>Actually, I meant what was said, which is that the leading and
trailing #xA are added to *children of the root node* with the document
order characteristics given in Section 2.3.  Only comments outside of the
top-level document element can be children of the root node.
    a.. As an example of the previous point, the "Canonical Form
(commented)" example in the table of section 3.1 should (according to the
existing rules) have a leading #xA prior to "Comment 1."
    b..
    c.. <john>Actually, the point of examples was to make sure everybody
understood exactly what was meant by the prose in the specification.  There
should not be a leading #xA prior to Comment 1 because it is a child of
element <doc>, not a child of the root node.</john>
    d..
    e.. Since validating XML processors are required to normalize (remove)
any leading or trailing whitespace in an attribute value where that
attribute is declared to be of a type other than CDATA, the canonical form
for the normId element in section 3.4 should be <normId id="'
&#xD;&#xA;&#x9; '"></normId>.  That is, this example should not have a space
between the enclosing quotation marks and the first and last apostrophes.
  <john>Agreed.  In [1], I mentioned this to Karlinger.

  [1]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0492.html

  So, in summary, I intend to fix example 3.4 in the way described in [1],
and I intend to add a parenthetic clarifying the loss of comments in DTDs
due to loss of DTDs in Section 2.1.  Good?

  Thanks,
  John Boyer

  </john>

  thanx,
      doug

  Doug Bunting
  cXML Standards Manager
  Ariba, Inc.

  -----Original Message-----
  From: John Boyer [mailto:jboyer@PureEdge.com]
  Sent: September 11, 2000 14:51
  To: Doug Bunting; TAMURA Kent; Muraw3c@Attglobal. Net; Anli Shundi;
lesch@w3.org; Martin J. Duerst; Petteri Stenius
  Subject: Last Call


  Hi all,

  You are getting this email because the new September 7 version of C14N [1]
addresses last call issues that include changes based on your feedback.  It
would be very helpful if you could have a look at the last call issues list
[2], read the resolutions, and send an email to the dsig group to indicate
either that you are satisfied that your issue was resolved or if you require
further changes.

  PLEASE SEND YOUR RESPONSE TO THE DSIG GROUP so I can provide links from
the last call document to your affirmation.

  Thanks for your patience and kind attention to this matter.  We would like
to submit for candidate recommendation next week, so if you could cut some
time out of this week to do this, I would really appreciate it.

  [1] http://www.w3.org/TR/2000/WD-xml-c14n-20000907
  [2] http://www.w3.org/Signature/2000/09/06-c14n-last-call-issues.html

  Thanks,

       John Boyer
        Development Team Leader,
        Distributed Processing and XML
        PureEdge Solutions Inc.
        Creating Binding E-Commerce
        v: 250-479-8334, ext. 143  f: 250-479-3772
        1-888-517-2675   http://www.PureEdge.com