W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > August 2003

RE: xmlsch-02

From: <Patrick.Stickler@nokia.com>
Date: Wed, 27 Aug 2003 14:07:34 +0300
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B5FBC4B@trebe006.europe.nokia.com>
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.

Received on Wednesday, 27 August 2003 07:08:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:25 UTC