Re: Alternate parseType Issues

Hi Aaron,

I'd like to see if we can try and clarify what the issues here are.

Aaron Swartz wrote:
> 
> There are some issues in the current RDF spec[1] with alternate parseTypes
> (currently used by DAML and CWM).
> 
> The first is that alternate parseTypes, while allowed by the text of the
> specification, are not allowed by the grammar which constrains them to
> either Resource or Literal.
> 
> Also, while the text of the spec says:
> 
>     With RDF 1.0 other values must be treated as identical to 'Literal'.

So I'm not sure that's really that inconsistent.  Only parseType's 'Resouce'
and 'Literal' are allowed, either by the the grammar or by the the text.
There is a statement, defining the behaviour for RDF 1.0, should it be
processing something other than RDF 1.0.  My guess is that was done so
that those defining new parseType's would know exactly how it would be
processed by an RDF 1.0 processor, even though it was not legal RDF 1.0.

> 
> It does not state that the value of the parseType must be passed along with
> the literal, which seems essential for proper processing by an application.

M&S is about defining the language and its interpretation.  It doesn't
talk about processing models, API's for parsers or the like.  When you talk
about the parseType being passed along, what is it being passed from and to.
We have no language in the spec to talk to about that.

> 
> Finally, it would be nice if parseTypes were namespace qualified, as DAML
> (daml:collection) and CWM (log:Quote) seem to have done. However, the
> semantics of these QNames is unclear, as DAML seems to state the name must
> be daml:collection regardless of the prefix for the DAML namespace in the
> document.

That's an interesting thought.  I guess the web principal is that everything
should be identified by a URI, and then daml:collection could be thought
of as an encoding of a URI.

That sort of thing is only really needed though if we expect parseType to be
used as a kinda general purpose extensibility mechanism where anyone can 
come along and define a new parse type.  If there are just a few of them
defined by the language, then its a controlled vocabulary and we don't need
an open naming scheme like that.

So I'm wondering if the issue you are really getting at here is to propose
that the spec acknowledge that parseType's can be defined by anyone as an
open extensibility mechanism.  

Do tell if I've missed the mark.

Brian

Received on Tuesday, 12 June 2001 06:11:37 UTC