Re: Qnames in attrs and c14n

Quoting "Henry S. Thompson" <ht@cogsci.ed.ac.uk>:

> jon@hackcraft.net writes:
>
> > Quoting "Henry S. Thompson" <ht@cogsci.ed.ac.uk>:
>
> <snip/>
>
> > Canonical PSVI serialisation and reverse the no-namespace-prefix-rewriting
>
> > resolution?
>
> I wouldn't insist on PSVI, if by that you mean W3C XML Schema --
> instead we could/should consider taking the XQuery route and saying,
> roughly, "You need types to do this.  You could get them by
> schema-validation with W3C XML Schema, but if you get them some other
> way that's OK too."
>
> > Whenever I read the c14n spec that idea always occurs to me, but it always
>
> > seems messy after a bit more thought.
>
> Messy, perhaps, but worth it none-the-less?
>

Well the most messy thing about it is whether we insist on W3C XML Schemata, or 
if not what features we require from the schema system used.

A minimum to solve the qnames in attributes problem is that we should know if 
an attribute is of type QName, and to ignore typing issues with anything else.

But then, what of QNames as element content? what about types derived from 
QName (a list of QNames, QNames with an enumeration of pattern constraint that 
forces them to have a particular prefix, or one of a particular range of 
prefixes, and of course strings that contain QNames such as xpath expressions)? 

Even if we insist on W3C XML Schema to get around the issue of clashes between 
different forms of schemata this is not going to have an pretty resolution.

Maybe the best way to look at this is to widen our perspective out past QNames 
and look at the variety of differences XML documents can have while being 
considered identical to a given application. Tim's original post mentioned 
potential serialisations of RDF, but given the innately unordered nature of RDF 
triples we would expect a serialisation to have no order. Are we going to allow 
for a canonical ordering operation for such documents (whats the fastest we can 
sort a large document, O(log n)? O(n log n)? after loading the whole thing into 
memory? Ouch!). When we widen our perspective this far it's tempting to 
conclude that we aren't going to come up with a general solution, and that more 
than one form of c14n is needed (indeed already 2 forms exist, 4 if you count 
the with and without comments options as seperate forms).

Multiplying the number of c14n forms is messy as well, but I think it could be 
workable (maybe).

Received on Thursday, 27 November 2003 12:52:13 UTC