Mailing-List: contact xmlbeans-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: xmlbeans-dev@xml.apache.org
Mime-Version: 1.0 (Apple Message framework v618)
In-Reply-To: <40E5EC4F.3010004@wingsofhermes.org>
References: <4B2B4C417991364996F035E1EE39E2E1DCE2F3@uskiex01.amer.bea.com>
 <1088699043.5276.33.camel@newlyn2.providerlink.com>
 <de70b39d04070112136da73703@mail.gmail.com>
 <91D3E563-CBA4-11D8-B6FD-000A95C89D86@akuma.org>
 <de70b39d040701143022f5a1c8@mail.gmail.com>
 <5A2D8958-CBA8-11D8-B6FD-000A95C89D86@akuma.org>
 <de70b39d040701170070c90f12@mail.gmail.com>
 <40E5EC4F.3010004@wingsofhermes.org>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <9695B0B4-CC81-11D8-B6FD-000A95C89D86@akuma.org>
Content-Transfer-Encoding: 7bit
From: David Waite <mass@akuma.org>
Subject: Re: xmlbeans xml security
Date: Fri, 2 Jul 2004 18:43:15 -0500
To: xmlbeans-dev@xml.apache.org


On Jul 2, 2004, at 6:14 PM, Berin Lautenbach wrote:

> Noah Campbell wrote:
>
>> As I understand c14n (and I'm learning volumes as I prepare to
>> implement a C14NSaver) the namespace is discarded in the
>> cananocialized form.  Sure the output is not xml valid, or namespace
>> collisions cause a lossy form, but this is okay.  The point is not to
>> have a valid doc but a representation that will be unique on a byte
>> level.
>
> David's already answered this - but just to cover off.  Attribute 
> qnames and namespaces are fully included in a canonicalised document, 
> except exclusive C14n, where they will be discarded if they are not 
> actually used.  This is because namespaces impact the meaning of a 
> document, and namespace prefixes could potentially be used to define 
> some meaning in the doc (although I truly hope not!).  A signature 
> must be made invalid if anything in the document changes that might 
> impact it's meaning.

Actually, an earlier draft did rework namespaces to have canonical 
names (probably x0, x1, ...). The problem is that namespace prefixes 
indirectly do provide meaning in the doc, due to things like qname and 
xpath types... I can only guess there was a fear that requiring 
anything more than DTD, or anything beyond what a non-validating parser 
is required to do (such as normalize or expand attributes based on the 
DTD) was opening the flood-gates.

> The output of C14n will be a well formed document for a full document 
> or full sub-tree canonicalisation.  Where an XPath (or other) 
> transform has selected nodes that together do not provide a well 
> formed document the output will not be well-formed.  (There are some 
> fantastic test cases for c14n interoperability that give truly weird 
> outputs :>.)

Where are these test cases located? I had trouble finding them from the 
w3c site.

> For full document canonicalisation, I cannot easily think of a 
> document where the canonicalised form would not be valid if the input 
> document was valid (maybe exclusive c14n where default namespaces 
> attributes were discuarded?).  C14n is really just a strongly defined 
> serialisation routine.

Exclusive canonicalization will only discard prefix->namespace mappings 
if they are already declared in-scope they are declared on elements 
which aren't in the node-set, and aren't used on child element names or 
their attribute names included in the node set.

-David Waite


- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/