W3C home > Mailing lists > Public > www-rdf-comments@w3.org > January to March 2001

Re: SiRPAC bugfixes

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Tue, 13 Mar 2001 10:32:25 +0000
Message-ID: <3AADF739.5AF8AE67@hplb.hpl.hp.com>
To: www-rdf-comments@w3.org, aswartz@upclink.com, ottoka@cs.tu-berlin.de, barstow@w3.org
I've been reviewing this thread for adding it to the issues list.

The rdf fragment:

  <rdf:li />

does not match the container specific production for rdf:li, i.e.
production 6.30.  All production 6.30 options require the element to
have (possibly emtpy)
content.

For parsers that require containers to match the container specific
productions therefore, the above fragment is illegal RDF.

There remains the issue of the interpretation of:

  <rdf:Description >
    <foo:bar />
  </rdf:Description>

The foo:bar element must match production 6.12.  This production has
only one
option which allows an empty element.  This structure should therefore
be interpreted as matching the last option in production 6.12, in which
the object of the statement is a resource.

I would be grateful for an indication of whether these observations
resolve the issue.

Brian





> SiRPAC bugfixes
> 
> From: Karsten-A. Otto (ottoka@cs.tu-berlin.de)
> Date: Fri, Feb 23 2001
> 
> *Next message: Cupid@LRFP.eweeklyclassifieds.com: "your love connection -GHFE"
> 
>    * Previous message: Dan Connolly: "RDF Syntax: An XML Schema Approach"
>    * Next in thread: Art Barstow: "Re: SiRPAC bugfixes"
>    * Reply: Art Barstow: "Re: SiRPAC bugfixes"
>    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>    * Other mail archives: [this mailing list] [other W3C mailing lists]
>    * Mail actions: [ respond to this message ] [ mail a new topic ]
> 
>   ------------------------------------------------------------------------
> 
> Date: Fri, 23 Feb 2001 23:59:56 +0100 (MET)
> From: "Karsten-A. Otto" <ottoka@cs.tu-berlin.de>
> To: www-rdf-comments@w3.org
> Message-ID: <Pine.SOL.4.10.10102232311440.6823-100000@paula>
> Subject: SiRPAC bugfixes
> 
> Hi,
> 
> while testing the SiRPAC parser I encountered two cases where the parser
> produced weird results. These are listed below, together with suggested
> bugfixes.
> 
> Case one: The parser simply swallows empty container elements:
> 
> <rdf:Alt ID="foo">
>     <rdf:li/>
>     <rdf:li>bar<rdf:li>
> </rdf:Alt>
> 
> becomes
> foo , rdf:type , rdf:Alt
> foo , rdf:_2 , "bar"
> 
> without the expected
> foo , rdf:_1 , ""
> 
> This can be fixed by adding a special case handler to processListItem, in
> the else branch roughly at line 1760. Put the following before the while loop:
> 
> if (!e.hasMoreElements())
>   addTriple (createResource(RDFMS+"_"+iCounter),
>              createResource(sID),
>              createLiteral(""));
> 
> This makes sure something is done for empty list elements too.
> 
> Case two: The parser treats empty properties as resources instead of literals:
> 
> <rdf:Description ID="foo">
>     <x:empty/>
>     <x:empty></x:empty>
> </rdf:Description>
> 
> becomes
> foo , x:empty , #genid1
> foo , x:empty , #genid2
> 
> while it should be
> foo , x:empty , ""
> foo , x:empty , ""
> 
> This one is more complicated. The problem lies in processPredicate, where the
> comment at line 1566 says
> 
> /**
> * Before looping through the children, let's check
> * if there are any. If not, the value of the predicate is
> * an anonymous node
> */
> 
> I think this is wrong in most cases. This condition is results in a triple
> with a #genid, see line 1580:
> 
> addTriple (createResource(predicate.name()),
>            createResource(sTarget),
>            createResource(sObject));
> 
> If you change the createResource(sObject) to createLiteral(""), it works as
> expected. However, it then also applies to this strange case:
> 
> <rdf:Description ID="foo">
>     <x:empty ID="bar"/>
> </rdf:Description>
> 
> While this is legitimate, I am not too sure what it is supposed to mean;
> I assume a reification with an empty object or something like that. You can
> identify this by checking (sStatementID != null), but as I said I am not sure
> how to handle this...
> 
> Maybe the empty peroperties should already be recognized in an earlier parsing
> state, such as treating them as parseLiteral in endElement. This actually
> works if you force it as in
> 
> <rdf:Description ID="foo">
>     <x:empty rdf:parseType="Literal"/>
> </rdf:Description>
> 
> You also could change the parseLiteral method to return true if there are no
> non-rdf/xml attributes on the stack, but since this method is used so often
> in the code I am not sure of the implications.
> 
> I hope this was some help!
> 
> Regards,
> Karsten Otto
> 
>   ------------------------------------------------------------------------
> 
>    * Next message: Cupid@LRFP.eweeklyclassifieds.com: "your love connection -GHFE"
>    * Previous message: Dan Connolly: "RDF Syntax: An XML Schema Approach"
>    * Next in thread: Art Barstow: "Re: SiRPAC bugfixes"
>    * Reply: Art Barstow: "Re: SiRPAC bugfixes"
>    * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>    * Other mail archives: [this mailing list] [other W3C mailing lists]
>    * Mail actions: [ respond to this message ] [ mail a new topic ]
Received on Tuesday, 13 March 2001 05:31:28 GMT

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