W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > September 2001

RE: quick question/request about syntax wdraft

From: dehora <dehora@eircom.net>
Date: Fri, 7 Sep 2001 04:22:54 +0100
To: "RDFCore" <w3c-rdfcore-wg@w3.org>
Message-ID: <000001c1374c$62d28310$01000001@MITCHUM>

> From: Brian McBride:
> dehora wrote:
> > 
> >
> > Brian, I would say that this was proposed syntax change: it 
> sounds less
> > dramatic ;) 
> Didn't mean to sound dramatic.  I suppose I'm looking at the charter
> and dragging my feet again.

Completely reasonable.

> Personally, I'm sympathetic to this change.  However, I'm not sure
> there is a problem here we need to fix.  What difference would it make
> if we did nothing?

I hope none: but if the parseType attribute ever gets crowded it's an
obstacle in insuring that literals are interpreted consistently.
Namespace partitioning  in this case seems wholly consistent with web

> What is unclear exactly?

I accept defeat on clarity in the M&S on this matter. 

It's perfectly clear: essentially the recommendation over rdf:parseType
is a hedge in the M&S. RDF wgs have the option on _any_ future value
name plus interpretation for the name, while not saying outright to
coders and modellers, don't process or create any new ones. The
recommendation admits that the area is not fully understood going to
print, and actually encourages and expects future wgs to clarify: thus
the option (and a reasonable one at that). Meanwhile the W3C now has art
using namespaced attribute values, and, there is solid feedback on how
this part of RDF-XML is being used. That's why I think this change is
non-controversial wrt the charter; what would need to be resolved is the
binding/constant issue Jan raised and whether there are any ugly
fragment/transform issues that make namespace binding too painful. 

RDF doesn't need a veto on all the values, just some of them: the M&S
seems over constrained at this point. DAML and Tim Berners Lee have had
the foresight to use a prefixed value that will play with namespaces;
possibly we can't expect others to do likewise.

What is _not_ perfectly clear is whether M&S users should crack ahead
and extend parseType in the hope that if the M&S catches up, it won't
run them over. Whatever about qualifying parseType attributes, the wg
should export a clear stance on the matter of parseType extensibility.

Bill de hÓra
Received on Thursday, 6 September 2001 23:23:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:04 UTC