Re: Alternate parseType Issues

Aaron Swartz wrote:
> 

> I'm not talking about processors. I'm simply talking about parsers here.

I tend to use the term 'rdf processor' to mean anything that processes RDF.
RDF parsers are a subset of 'rdf processors'. You use it differently.
Thats what I meant about not having a vocabulary defined for this stuff.

> The
> RDF spec clearly states in the prose that parsers must accept parseTypes
> with other values. That this is not also in the grammar is a mistake. I
> don't see how it could be any other way.

Have you looked at the possibility that the grammar defines legal RDF 1.0
and the text specifies how to handle a particular case of illegal RDF?

What the spec actually says is:

  The parseType attribute changes the interpretation of the element
  content. The parseType attribute should have one of the values 'Literal'
  or 'Resource'. The value is case-sensitive. The value 'Literal' 
  specifies that the element content is to be treated as an RDF/XML
  literal; that is, the content must not be interpreted by an RDF
  processor. The value 'Resource' specifies that the element content
  must be treated as if it were the content of a Description element.
  Other values of parseType are reserved for future specification by RDF.
  With RDF 1.0 other values must be treated as identical to 'Literal'. 

Hmmm.  "...should have one of the values ...".  According to:

  http://www.isi.edu/in-notes/rfc2119.txt

"should" means:

  SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.


> 
> >> Well, what I am really getting at is that like it or not, parseTypes are
> >> being used as an open extensibility mechanism ... and so we should document
> >> this feature.
> > So I think the core issue you are raising here then is opening up
> > parseType as an extensibility mechanism.
> >
> > I guess my question here is whether there is anything actually broken
> > with the current spec that needs fixing.  Or is this a this would be nice
> > to have feature?
> 
> Yes, there is clearly something broken here.

Remind me.  What exactly?

> a third is in our goal of remaining compatible with DAML

We have an issue:

  http://www.w3.org/2000/03/rdf-tracking/#rdf-containers-otherapproaches

which must take into account the DAML experience.

> and other
> implementers (which I feel requires us to provide a response to their work
> on daml:collection)

What other implementors.  If you are thinking of parseType="Quote" then
we have:

  http://www.w3.org/2000/03/rdf-tracking/#rdfms-quoting

> and a fourth is:
> 
>   http://www.w3.org/2000/03/rdf-tracking/#rdfs-xml-schema-datatypes

I don't get the connection with that one, but we do seem to have it
covered.

Do you see what I'm trying to do here.  I'm trying to capture the problems
in the issue list, not a proposed solution.

I'd like to be clear about what is broken, or whether this is an
enhancement.

Brian

Received on Tuesday, 12 June 2001 14:33:53 UTC