Re: Notes on xml-exc-c14n rev 1.21

On Wednesday 09 January 2002 04:28, Thomas Maslen wrote:
> Very likely I just need a remedial reading comprehension class, 

Hardly, it's clear you read it carefully (and implemented as you note) and 
it is great to get such detailed comments! (Will you be willing to do 
report on interop?)

> came across a number of places in the current editors' copy (r 1.21) of
> the Exclusive XML Canonicalization spec where I ended up relying on my
> intuition about the intent of the spec because (as far as I could tell)
> details were either missing or inaccurate.

Ok, resulting document is:
  $Revision: 1.22 $ on $Date: 2002/01/09 23:02:23 $

I first address comments that prompted a tweak and will send a another 
email with issues I've deferred because I'm stilling thinking about or hope 
others will contribute.


> Semantic issues:
>     (1)	"output parent" vs "output ancestor"

Agree. I've attempted to define output ancestor  and change "output parent" 
to "output ancestor" in those instances necessary.

> Consistency & Clarity:
>     (a)	"apex node" is specifically defined for element nodes, whereas
> 	"orphan node" doesn't mention a node type.  If this is deliberate,
> 	i.e. the definition applies to namespace and attribute nodes too,
> 	then it should be explicit rather than implicit.

I'm going to provisionally insert "orphan node is a/+n element+/ node ...". 
In every instance we use it that's why is meant I think though I do wonder 
about XPath selection that would only select an attribute: the attribute is 
certainly orphaned -- canonicalizing non-well formed XML... John?

>     (b)	"output parent" is undefined for apex nodes.  Fair enough, but
> can this be stated explicitly?

/+an apex node has no output parent.+/

>     (c)	"visibly utilizes" is defined.  "utilizes" is not.  Step 3.1 of
> the algorithm in Section 3 says "Render each namespace node iff it is
> [...] utilized by [...]".  Did it mean "visibly utilized"?

Yes, fixed.

>     (d)	The definition of "visibly utilizes" includes both the prefix (P)
> 	and the bound value (V), and talks of a "namespace declaration".
> 	The first two uses of "visibly utilizes" include the prefix but
> 	not the bound value.  The third use of "visibly utilizes" [well,
> 	the one that just says "utilizes" at present] talk about the
> 	namespace node and the InclusiveNamespacePrefix List.
> 	These all seem rather inconsistent.  My guess is that the definition
> 	should refer only to the prefix (P) and not mention the bound value
> 	at all.

Ok, given its usage I've defined visibly utilizes to include only P. 
Elsewhere, when concened with P and V I'm more explicit.

>     (f)	Step 3.1 of the algorithm in section 3 says "Render each
> namespace node iff [...] it has not yet been rendered [...] by an output
> parent".
> 	This means the output parent of the namespace node, i.e. the element
> 	node.  Is this really what was intended?  Or did it really mean to
> 	say an output parent of the element node?  (Even then, "an" doesn't
> 	make sense unless "output parent" is replaced by "output ancestor").

Output ancestor, fixed from previous comment.

>     (g)	The pseudocode is too pseudo.  In particular, the offhand use of
> 	ns_rendered is much to vague -- having implemented this, I can
> 	guess what it really means, but the pseudocode doesn't define it
> 	for me.

I've added some more explaination, let me know if that helps -- or makes it 
worse! <smile/>

>     (h)	The DTD, the schema and the example now consistently refer to an
> 	"InclusiveNamespaces" element with a "PrefixList" attribute.  Good.
> 	However, the introductory text three lines above the example still
> 	refers to an "InclusiveNamespacePrefix" element with a "List"
> 	attribute, and six other places in the document also refer to an
> 	"InclusiveNamespacePrefix List".


>     (i)	Maybe just showing my ignorance...  why does the DTD for the
> schema declare %p; and %s; and not use them?  Likewise for &dec;

We're going to need a FAQ on that one!

>     (j)	It might be helpful if the text made it obvious that it is always
> 	using the XPath semantics for namespace nodes (well, except in the
> 	definition of "visibly utilizes"), i.e. the namespace axis of an
> 	element includes all the namespace nodes from its ancestors (except
> 	for overridden bindings, and except for the absence of xmlns="").
> 	The paragraph in section 1.1 says (most of) this, but a little
> 	reinforcement wouldn't hurt, particularly in section 3.

I added some text to the example implementation comment on the fact that 
many XPath implememtations don't make a namespace axis available.

Received on Wednesday, 9 January 2002 18:04:17 UTC