Re: Prefix rewriting considerations

Scott Cantor schrieb:
>> Don't you get such qname problems as well with rewriting prefixes to
>> "ns$i" or to base64(hash(ns-uri))?
>>     
>
> Yes, but we're handling that now (to the extent we can). The point is, what
> does "simplifying" the other cases buy us if we still have to address the
> prefixes anyway?
>   
This depends on the scenario. If the XML Signature is intended to be
placed and verified on a single document, there is no need to rewrite
the prefixes at all, agreed. However, if you want to "recycle" a
signature, e.g. use the same signed fragments of an XML document in new
documents (e.g. data variables in SOAP messages of Web Service
compositions), you might run into problems with the prefixes chosen on
signature application.
Another benefit is that PFC14N can easily and rapidly be done in the
streaming case, without the need to store namespace definition stacks or
ponder about where to put which namespace declaration. The complete
"visibly utilized" stuff (that actually made EXCC14N rather complex) can
be omitted, since you don't need the namespace declarations anymore.
>   
>> I mean, this is about
>> canonicalization, hence direct input to digest computation. If you'd do
>> a prefix rewrite in *any* way, such references to "xsd:string" will be
>> broken in the c14n'ed XML.
>>     
>
> Unless you rewrite them too.
>   
OK, I got the point. Agreed, this is something that PFC14N indeed does
not support.
>   
>> Regarding attributes: you'll only need prefixes if an attribute is from
>> a different namespace than its element (rare case).
>>     
>
> It's not really that rare (xsi:type being one obvious case, SOAP being
> another).
>
>   
>> Then you can define
>> an arbitrary prefix (e.g. using the "ns$i" approach) at that element,
>> which thus is only relevant for that single attribute(s) at this
>> particular element. Advantage is that you don't have to deal with issues
>> of identical prefixes mapping to different namespace uris.
>>     
>
> The point is that it defeats the simplification you're suggesting exists
> when the exceptions are quite common.
>   
well, the tradeoff here is either dealing with some attributes or
dealing with lots of namespace mappings in XML subtrees. I think it
largely depends on the scenario, but I have to admit you're right:
PFC14N is not suitable to support all use cases.

best regards

Meiko

Received on Tuesday, 13 April 2010 21:05:17 UTC