- From: <Patrick.Stickler@nokia.com>
- Date: Wed, 27 Aug 2003 14:07:34 +0300
- To: <jjc@hplb.hpl.hp.com>, <bwm@hplb.hpl.hp.com>
- Cc: <danbri@w3.org>, <w3c-rdfcore-wg@w3.org>, <Patrick.Stickler@nokia.com>
> 5) Variant of Fudge - e.g. make it clear in the implemenation > note that > additional whitespace is an error, make producing a warning a > SHOULD rather > than a MAY. (Probably not enough to appease Peter, may head > off others), > could even make the implementation note informative and down > case the MAYs > and SHOULDs. I think this is the most promising path. Making the stuff informative seems like a good idea. Also, we should state that implementations MUST product valid lexical forms when generating RDF/XML. That will address the interoperability concerns to a better degree. I.e. we are simply taking the "strict in what you produce, flexible in what you accept approach". " 10 "^^xsd:integer *is* an invalid typed literal, and its occurrence in an RDF/XML serialization, or graph, *is* an error, but RDF applications are free to recover from such an error if they feel that a coercion which (exceptionally) includes whitespace processing is reliable, just as they are free to choose to recover from any error if they can. RDF implementations which purport to implement support for XML Schema datatypes and fail the tests in question *are* broken. Cest la vie. In the long run, I think that taking a strong stance on this will *help* interoperability, and the integration between disparate solutions which employ or map to XML Schema datatypes as I'm sure that many if not most will not include any form of whitespace processing in their datatyping models. Patrick
Received on Wednesday, 27 August 2003 07:08:40 UTC