RE: pfps-06 hold off?

> -----Original Message-----
> From: ext Brian McBride [mailto:bwm@hplb.hpl.hp.com]
> Sent: 27 August, 2003 17:31
> To: Stickler Patrick (NMP/Tampere)
> Cc: phayes@ihmc.us; w3c-rdfcore-wg@w3.org
> Subject: Re: pfps-06 hold off?
> 
> 
> Patrick.Stickler@nokia.com 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.
> 
> I agree with you Patrick that we cannot change the definition of the 
> lexical space of an xsd datatype, or the mapping from that 
> space to the 
> value space.
> 
> However, it did occur to me that we could choose to adopt a scheme 
> something like you suggest below.
> 
> > 
> > All that we could do ourselves would be to say that the RDF
> > L2V mapping, for XML Schema datatypes, includes the whitespace
> > processing, but such a position creates such blatant dependencies
> > and other nastiness in our design that simply thinking about
> > such a thing happening makes my ass start to twitch.
> 
> Could you spell out for me what 'blatant' dependencies are 
> created and 
> what other nastiness is created.

Blantant dependency: only XML Schema defines whitespace processing
formally, and as the RDF Datatyping is intended to be agnostic
about how datatypes are defined -- so long as they fit within the
constraints defined for rdfs:Datatype -- making explicit mention
of XML Schema specific machinery creates a blantant dependency
between RDF and XML Schema.

Other nastiness: how does RDF datatyping then relate to other
datatype frameworks which do not formally define whitespace
processing in relation to datatype definitions yet supporting
tools perform a sort of whitespace processing on input? This
opens a pandoras box regarding implementational and processing
details that should be out of scope for our specification.

> > Can you please, if possible, clarify what basis you have for
> > suggesting that the XML Schema L2V mapping might change, or
> > that the RDF L2V mapping would not be the same for XML Schema
> > datatypes as defined by XML Schema?
> 
> I simply, in my ignorance, don't know why your ass twitches.

Because we are justifying a design change based on the behavior
of tools which are being used *out of their intended context*.

I.e. the argument goes, that because for common tools such
as Xerces and .NET, the following entailment holds

:Jenny :age "10"^^xsd:integer .
entails
:Jenny :age " 10 "^^xsd:integer .

then RDF should treat " 10 " as a valid lexical form for
xsd:integer (though XML Schema says it is not) or RDF should
say that whitespace processing is part of the L2V mapping 
(though XML Schema says that it isn't).

But on the same basis, we could further argue that because
for both Xerces and .NET, the following entailment holds

:Jenny :age "10"^^xsd:integer .
entails
:Jenny :age "10.0"^^xsd:integer .

then RDF should treat "10.0" as a valid lexical form for
xsd:integer; which is most definitely false according to
the XML Schema specs and has nothing to do with whitespace
processing at all.

I.e. the bottom line is that those XML tools are not actually
performing any kind of lexical form validation nor requiring
that lexical forms actually be valid -- only coercible -- and
to make design decisions for RDF, which requires a far higher
degree of precision than most XML tools, based on such behavior
is pretty piss poor engineering, IMMHO.

This is certainly an issue to be addressed, and must be addressed
to achieve optimal integration between RDF and XML, but changing
our datatyping model is IMO the wrong way to address it.

It is very similar to the issue of how to insert XML fragments
into RDF graphs. You can't just toss raw XML content into RDF. You
have to pay attention to certain issues such as how to capture
contextual information for fragments, how to normalize XML fragments,
and in fact how to normalize *any* lexical form coming from an XML
context where things are less precise than in the RDF world, such
as dealing with extra whitespace that is OK in an XML context but 
not in an RDF context. 

> > 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.
> 
> Consider a meeting with the director requesting advancement to PR.
> 
> Director:  Hmmm, quite a few of the implementations seem not to be 
> implementing this test case.
> 
> WG:  That's because we defined the L2V mapping strictly 
> according to XSD 
> datatypes and don't include white space processing.
> 
> Director:  Well, if that is what the implementations are doing, why 
> don't you allow white space processing in the mapping.
> 
> WG: ...
> 
> Can you help me out with the WG's response.

See my arguments above. That's precisely what I would say to the director.

Patrick

Received on Thursday, 28 August 2003 05:34:12 UTC