- From: Graham Klyne <GK@NineByNine.org>
- Date: Tue, 04 Mar 2003 14:31:08 +0000
- To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Cc: pat hayes <phayes@ai.uwf.edu>, w3c-rdfcore-wg@w3.org
Er, Jeremy, which requirements does Pat's suggestion not meet? #g -- At 11:52 PM 2/28/03 +0000, Jeremy Carroll wrote: >>I took this comment as a rhetorical question meaning, "why bother even >>getting into canonicalization if you have implementation variance?" and >>hence suggesting a fourth option, which you did not consider: >>D. Ignore XML canonicalization and treat XML literals as strings, ie the >>L2V mapping is the identity. >>Then the entire rdf:XMLliteral datatype machinery is just an elaborate >>way of encoding the old 'XML bit', which I thought was the original >>intent in any case. Introducing XML canonicalization seems to have been >>one those neat ideas that got slipped in without too much discussion and >>has turned out to be a tar-pit. I am particularly concerned that this >>ugly mess is now centrally included in the very core of RDF. I would hope >>that many 'cheap and cheerful' RDF engines wouldn't even want to know >>about XML, still less about XML canonicalization. > >This really does not meet the requirements ... > >XML parsers really really have variability, when building RDF/XML parsers >we have to work out how to deal with that. > >So the simple webont examples where they want a single well-defined >denotation of some literal constructed with an rdf:parseType="Literal" >cannot be addressed simply by saying "use the original string". > >In some real contexts there isn't a string to use (e.g. parsing a DOM tree). > >We could have put all the work in the parser, and then the semantics could >just use the string - that may be your preference, but it's too late now. >In practice I would expect a webont impl to work that way. However, I also >believe in practice that there will be cheaper parsers for low footprint >environments which don't do this. > >Jeremy ------------------- Graham Klyne <GK@NineByNine.org> PGP: 0FAA 69FF C083 000B A2E9 A131 01B9 1C7A DBCA CB5E
Received on Tuesday, 4 March 2003 10:21:05 UTC