W3C home > Mailing lists > Public > www-rdf-comments@w3.org > April to June 2005

Re: Error in RDF/XML Syntax Specification?

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 6 Apr 2005 09:48:14 +0300
Message-Id: <749b4d81ba2d5133a7f9fac61a5ccb81@nokia.com>
Cc: www-rdf-comments@w3.org, Arjohn Kampman <arjohn.kampman@aduna.biz>, Dave Beckett <dave.beckett@bristol.ac.uk>
To: "ext Pat Hayes" <phayes@ihmc.us>


OK. Thanks, Pat. So then for datatypes which do not
have null lexical forms we treat a null lexical form the
same as any other invalid lexical form. I.e. both

    ""^^xsd:number
    "abc"^^xsd:number

are both invalid, for the same reason, that the specified
lexical forms are not in fact in the lexical space of the
specified datatype.

We then leave it up to the "owners" of a given datatype
to clarify whether or not the null lexical form is or
is not a member of the lexical space of the datatype.

Fair enough.

Cheers,

Patrick


On Apr 5, 2005, at 20:02, ext Pat Hayes wrote:

>
>> On Apr 5, 2005, at 12:35, ext Graham Klyne wrote:
>>
>>>
>>> While I agree with David and Arjohn that ""^^<datatype> SHOULD be  
>>> expressible,
>>
>> I'd like Pat Hayes' in put on that, before we decide this,
>> as I recall there being some issues with null lexical forms
>> with regards to the model theory.
>
> Im presuming that "" means the empty string, right? I don't think  
> there are any serious issues if that is true. For example,  
> ""^^xsd:string makes sense (I think. Its rather hard to discover if  
> the XML schema spec allows empty strings) but ""^^xsd:number doesn't  
> because the empty string isn't a legal lexical form for xsd:number.
>
> There might be some issues if we needed to have 'empty values' in  
> value domains, but I don't see that arising here.
>
>> It's probably OK, but best to be sure we don't break anything...
>
> :-)
>
> Pat
>
>
>>
>> Patrick
>>
>>> I think it's not quite such a no-brainer that it should be accepted  
>>> without Due Process.
>>>
>>> In cases like this, what is the W3C process for agreeing changes to  
>>> a published recommendation?
>>>
>>> #g
>>> --
>>>
>>> At 10:22 05/04/05 +0200, Arjohn Kampman wrote:
>>>
>>>> Dave Beckett wrote:
>>>>> On Fri, 2005-04-01 at 15:22 +0200, Arjohn Kampman wrote:
>>>>>
>>>>>> Hi Dave, others,
>>>>>>
>>>>>> Someone posted a bug report on the Sesame forum for what he  
>>>>>> thought was
>>>>>> an error in Sesame's RDF/XML parser[1]. I had a closer look at the
>>>>>> RDF/XML syntax specification[2] and it appears that Sesame  
>>>>>> strictly
>>>>>> adheres to this spec. This, however, surprised me, as I would have
>>>>>> expected the data to be correct. Also, the W3C Validation  
>>>>>> Service[3] did
>>>>>> parse the data as expected.
>>>>>
>>>>> Note that I'm speaking personally and not for any W3C WG.
>>>>> Don't take what that service does as necessarily correct.
>>>>
>>>> Guess you're no longer the editor of the spec? How does the W3C take
>>>> care of these post-release reports? It will probably need to be
>>>> documented in the errata.
>>>>
>>>>>> The problematic data contains a datatyped (xsd:string) empty  
>>>>>> literal:
>>>>>>
>>>>>> <?xml version="1.0"?>
>>>>>> <rdf:RDF
>>>>>>     xmlns="foo:bar#"
>>>>>>     xmlns:foo="foo:bar#"
>>>>>>     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
>>>>>>     xml:base="foo:bar">
>>>>>>
>>>>>> <rdf:Description rdf:ID="ID1">
>>>>>>         <foo:prop  
>>>>>> rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
>>>>>>         ></foo:prop>
>>>>>> </rdf:Description>
>>>>>> </rdf:RDF>
>>>>>>
>>>>>> If my understanding of the grammar in the spec is correct, then  
>>>>>> this
>>>>>> data matches the 'emptyPropertyElt' rule, which does not allow the
>>>>>> rdf:datatype attribute to be specified.
>>>>>
>>>>> Nope.  It does not match that rule.  rdf:datatype is forbidden on  
>>>>> an
>>>>> emptyPropertyElt.
>>>>> Looking at the rdf/xml grammar rules at
>>>>> http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/ 
>>>>> #section-Infoset-Grammar
>>>>> 7.2.21 emptyPropertyElt says the allowed attributes are:
>>>>>   set(idAttr?, ( resourceAttr | nodeIdAttr )?, propertyAttr*))
>>>>> and if you expand that you'll find
>>>>> 7.2.25 propertyAttr refers to
>>>>> 7.2.7 propertyAttributeURIs refers to forbidding the contents of
>>>>> 7.2.2 coreSyntaxTerms which includes rdf:datatype.
>>>>> Therefore this line SHOULD match instead 7.2.16 literalPropertyElt
>>>>> with an empty text() however 7.2.16 only applies to a non-empty  
>>>>> text.
>>>>
>>>> Well, 7.2.21 emptyPropertyElt already handles the case where no, or  
>>>> only
>>>> the optional rdf:ID attribute is present, generating an empty plain
>>>> literal as a result. Therefore, handling the rdf:datatype attribute  
>>>> in
>>>> the emptyPropertyElt production might be a good alternative.
>>>>
>>>>> Thus, in my opinion an datatyped RDF-literal with an empty content  
>>>>> is
>>>>> not covered by the grammar.
>>>>> This is a grammar coverage omission of what is legal to write in  
>>>>> RDF,
>>>>> and should be legal to write in RDF/XML.
>>>>
>>>> I agree. I'll fix this in Sesame/Rio, probably you and Graham (and
>>>> others?) should do the same for your parsers so that they exhibit
>>>> identical behaviour. Hopefully, someone will pick this up and  
>>>> document
>>>> it in the errata.
>>>>
>>>>> (This RDF/XML also is also passed as correct by the non-normative
>>>>> RELAX NG schema)
>>>>
>>>> The literalPropertyElt production in the RELAX NG schema contains an
>>>> other error, unrelated to the above: it only allows either an rdf:ID
>>>> attribute or an rdf:datatype attribute to be specified, but not  
>>>> both.
>>>> This is different from the normative grammar in chapter 7.
>>>>
>>>> Thanks so far,
>>>>
>>>> Arjohn
>>>>
>>>
>>> ------------
>>> Graham Klyne
>>> For email:
>>> http://www.ninebynine.org/#Contact
>
>
> -- 
> ---------------------------------------------------------------------
> IHMC		(850)434 8903 or (650)494 3973   home
> 40 South Alcaniz St.	(850)202 4416   office
> Pensacola			(850)202 4440   fax
> FL 32502			(850)291 0667    cell
> phayes@ihmc.us       http://www.ihmc.us/users/phayes
>
>
Received on Wednesday, 6 April 2005 06:53:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 21 September 2012 14:16:34 GMT