Re: Constrained implementation of exclusive C14N -- waht breaks?

Hi Pratik,

thank you very much for this very illustrative discussion/examlpes ...
please see below.

Pratik Datta schrieb:
> *Case 5:  Subtree with exclusions of subtree and then re inclusion of
> complete subtree (cannot be done with simple algorithm)
> *
> Supporting "re-inclusion" makes the algorithm more complicated,
> because there are missing ancestors in the middle too, and you need to
> take care of them.

What beyond namespace attributes and not xml:base/lang/space attributes,
would you need to take care of ?

What would be more complex then a simple push down for namespace
declarations xml:lang/space and the join-URI function already defined
for xml:base?


> *Case 6:  No restriction on element inclusions, but still limits on
> attributes
> *If we allow unlimited exlcusions and inclusions of elements, we end
> up with this.For this case we allow any elements nodes to be included
> / excluded regardless of position. But we put the following rules on
> attributes (note these rules are also applicable for cases 1-5)
>   a) cannot include an attribute, if its owner element is not in the
> nodeset
>   b) it is possible to exclude regular attributes, but not namespace
> attributes and not xml:base/lang/space attributes

That's where one (a User) should stop, when sensibly sub setting a document.
To constrain this however would require to constrain allowable
XPath/XPointer/XPathFilter 2.0 expressions.

And I think it's quite easy to treat the Case 7 under the assumption
that if Case 7 happens, what a User actually wanted is not of break the
InfoSet on the granularity of an Element.

>
> *Case 7: Further generalization with removing restriction on
> attributes, but still restrictions on namespaces (this is case that
> the exc C14N algorithm was talking about)
> *  In this scenario, attributes can exist without their owner
> elements, and xml: attributes are not treated specially.
> However namspace attributes can still not be removed.
> This is also the case that Konrad was talking about.

The approach I suggest iterates all the nodes of an input document and
when a node is reached that is in the node-set it's marked as visited in
the nodeset.
The inheritable context for xml:base/lang/space and namespaces is
maintained in stacks on the fly and pushed down into orphaned nodes,
it's really as simple as that.

(I'd prefer to synchronize namespace inheritance treatment consistently
with xml:base/lang/space inheritance. Unfortunately namespace
undeclarations are not likely to survive).

Best Regards
Konrad

-- 
Konrad Lanz, IAIK/SIC - Graz University of Technology
Inffeldgasse 16a, 8010 Graz, Austria
Tel: +43 316 873 5547
Fax: +43 316 873 5520
http://www.iaik.tugraz.at/content/about_iaik/people/lanz_konrad/
http://jce.iaik.tugraz.at/sic/products/xml_security

Downlaod certificate chain (including the EuroPKI root certificate):
http://ca.iaik.tugraz.at/capso/certs.jsp