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

Re: Issues concerning parseType

From: Ken Baclawski <kenb@ccs.neu.edu>
Date: Fri, 3 Aug 2001 00:04:27 -0400 (EDT)
To: Brian McBride <bwm@hplb.hpl.hp.com>
cc: www-rdf-comments@w3.org
Message-ID: <Pine.LNX.3.96.1010802235026.1746F-100000@steam>
On Wed, 1 Aug 2001, Brian McBride wrote:

> Hi Ken,
> Ken Baclawski wrote:
> > 
> > The RDF specification states: "The parseType attribute should have one of
> > the values 'Literal' or 'Resource'."  In addition, the formal grammar does
> > not allow for other values of this attribute.
> > 
> > However, the spec contradicts this requirement by allowing a parseType
> > other than Resource or Literal, and specifying that in this case it should
> > interpret it as if it was Literal.
> > 
> > These two specifications appear to conflict with one another.
> My own personal interpretation of these statements is that the M&S spec
> does constrain parseType to take values of either Resource or Literal.
> However the working group had the foresight to anticipate that new
> values may be defined in the future, and defined the behaviour that an
> an rdf processor built according to M&S 1.0 should exhibit if it
> encountered such an attribute value.  This makes it easier to define
> extensions.

I agree that it is useful to anticipate future extensions, but not at the
cost of making the current specification inconsistent.

> > This issue arose when I was puzzling over why SiRPAC was not giving me an
> > error message when I gave it the parseType "daml:collection".
> Personally, I would expect a parser to emit at least a warning message, and
> an error if in 'strict' mode.  There are number of issues known with SiRPAC
> and its behaviour should not be considered definitive.  There is a need
> for an improved 'reference standard' implementation of an RDF parser.
> Jeremy Carrol's recently announced ARP parser is a potential candidate for
> that role as it is automatically generated from the grammar.

Thanks for the pointers.  I also expected that some warning be issued, and
this led to my original problem.  However, the problem is not due to
SiRPAC not being definitive.  In fact, SiRPAC is consistent with the spec
in this case.  The problem is that the spec is not consistent with itself. 

> You might also try the Jena implementation with RDFFilter which has
> explicit support for daml:collection.
> > 
> > I subsequently also wondered whether the "daml" prefix in this case
> > should be interpreted as a namespace or as simply part of a literal.  In
> > particular, if I happened to use "abc" as the namespace for the DAML
> > schema, then should I use parseType="abc:collection" or
> > parseType="daml:collection"?  In other words, how should namespace
> > specifications be interpreted in literals, such as attribute literals or
> > parseType literals?
> That is a question you should better address to the daml community as
> they defined it.  I can tell you that the Jena version of RDF Filter
> assumes that daml:collection is a fixed string and takes no account
> of namespace prefixes defined in the document when processing it.

I'll try posting a comment about this.  It is certainly consistent to
assume that the daml:collection is a fixed string, but could also be
confusing if the daml: prefix refers to some other namespace in a

> I hope these observations are of some help.

Yes they have.  Thanks,

Ken Baclawski
Received on Friday, 3 August 2001 00:04:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:15:15 UTC