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

RE: pfps-06 hold off?

From: <Patrick.Stickler@nokia.com>
Date: Wed, 27 Aug 2003 13:58:58 +0300
Message-ID: <A03E60B17132A84F9B4BB5EEDE57957B02630237@trebe006.europe.nokia.com>
To: <Jan.Grant@bristol.ac.uk>
Cc: <phayes@ihmc.us>, <bwm@hplb.hpl.hp.com>, <w3c-rdfcore-wg@w3.org>, <Patrick.Stickler@nokia.com>



> -----Original Message-----
> From: ext Jan Grant [mailto:Jan.Grant@bristol.ac.uk]
> Sent: 27 August, 2003 13:33
> To: Stickler Patrick (NMP/Tampere)
> Cc: phayes; bwm; w3c-rdfcore-wg
> Subject: RE: pfps-06 hold off?
> 
> 
> On Wed, 27 Aug 2003, Patrick.Stickler wrote:
> 
> >
> >
> >
> > > -----Original Message-----
> > > From: ext pat hayes [mailto:phayes@ihmc.us]
> > > Sent: 27 August, 2003 04:16
> > > To: Brian McBride
> > > Cc: w3c-rdfcore-wg@w3.org
> > > Subject: Re: pfps-06 hold off?
> > >
> > >
> > >
> > > >Pat,
> > > >
> > > >I'm wondering whether we should hold off your following up
> > > pfps on pfps-06 as:
> > > >
> > > >   1) the xml schema lex 2 val mapping may be about to change
> >
> > Honestly, Brian, I'm wondering how this could happen. We do
> > not define the XML Schema L2V mapping, and the XML Schema
> > specs are quite clear that the L2V mapping does *not* include
> > whitespace processing, so I remain very puzzled at your
> > suggestion that this could change.
> 
> It's up to the XSD people to define, sure. However, there's 
> nothing that
> says the RDF L2V mapping has to be identical to the XML one; that is,
> they could quite conceivably say that the RDF L2V for their primitive
> types are compositions of whitespace processing and XML L2V.

I see no justification for us to say anything about XML Schema
datatypes normatively, nor do I consider it polite to define
an L2V mapping that is *different* from that defined by XML
Schema for XML Schema datatypes.

> > The few comments that we have recieved from implementors regarding
> > the looseness of the Xerces implementation does not IMO even
> > begin to justify any such changes.
> 
> The interop argument is the strongest technical one, I think. That is,
> if we add the WS processing, then it should be a MUST, not a MAY.

I don't find the "interop argument" as valid. 

If RDF implementors don't do the right thing, in producing RDF/XML,
such that their lexical forms are valid, then yes, there will be
an interoperability problem -- just as with any invalid RDF/XML.

I would expect that Xerces, and other XML tools, produce valid
lexical forms, without spurious whitespace, when mapping from
values to lexical forms, so implementors should not have any
trouble producing valid RDF/XML using those tools.

If, on the other hand, due to careless hacking and scraping from
XML content, invalid lexical forms happen to occur in an RDF/XML
instance, then RDF applications using XML Schema savvy tools
may be able to deal with those *errors* in a useful fashion.

The real issue here seems to be simply that some RDF applications
which employ Xerces are unnable to *identify* the invalid lexical
forms, because validation is based on successful coercion (not 
real validation) and Xerces is very forgiving in what it accepts
insofar as spurious whitespace is concerned, given the nature of 
the XML context.

The failure to perform a proper validation of the lexical forms,
in order to pass the tests in question, is clearly an implementational
flaw, and I still see no *technical* reason to change our design
to make it convenient for RDF implementors to be "sloppy".

The XML Schema specs are quite clear about what is a valid lexical
form. RDF typed literals do not live in the XML context and thus
whitespace processing is completely out of scope. There is no
technical reason to bring it into scope.

Again, I'm very sympathetic to the burden on implementors, but
bringing whitespace processing into the RDF scope is the wrong
way to approach this issue.

I think the last suggestion in Jeremy's recent post is the most
promising path.

Patrick
Received on Wednesday, 27 August 2003 07:02:05 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:59:42 EDT