Re: One last proposal

----- Original Message ----- 
From: "ext Martin Duerst" <duerst@w3.org>
To: "Patrick Stickler" <patrick.stickler@nokia.com>; <bwm@hplb.hpl.hp.com>
Cc: <w3c-rdfcore-wg@w3.org>; <w3c-i18n-ig@w3.org>
Sent: 14 July, 2003 20:55
Subject: Re: Proposal 2


> Hello Patrick,
> 
> Many thanks for your various proposals. I have now had time
> to look at them in detail.
> 
> I have to say that of all your proposals, I like this one
> best, because it brings us closest to the last call state.


Martin,

I expected that you would prefer proposal 2 to proposal 1, but also
point out again that adopting proposal 2 at this stage would impact
every component of the RDF specs and would surely require a 
second last call and several more months before we're done. I 
personally just don't see that happening. I wanted to write up the
details of the second proposal as an exercise in understanding what
you and the I18N were looking for in a solution, in terms of the
present specs. To that end, I think it was a useful exercise.

Please have a look at a refinement to proposal 1, in

http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jul/0165.html

As with proposal 1, this refined proposal  requires only minimal
tweaking to the RDF/XML syntax and its mapping to the graph,
but no substantive changes to the graph syntax, N-Triples syntax,
MT, existing test cases, etc.

It essentially provides M&S like literals and datatyped literals as
distinct methodologies, allowing one to choose which is optimal
for a given application. 

No, it does not provide a distinction between literals that look like
XML and those that are actual XML. But that appears to be the only
thing that I've understood you to be wanting which it does not provide.
And it is providing that particular distinction that would require
revamping nearly every corner of the present RDF specs.

> >    <#x> ex:foo "<xhtml:b>bar</xhtml:b>"^^ex:blargh .
> 
> I understand that Patrick cares a lot about such kinds of usages,
> and I somewhat understand the potential they have, but if
> I were the RDF WG, I would be rather careful to introduce
> them. For example, Patrick has mentioned the potential to
> use complex types here, and it is not clear to me that the
> datatype model that RDF Core has used for simple types is
> directly applicable for complex types.

The treatment of complex types using the RDF datatyping 
machinery is quite straightforward.

There are some options in how one defines the lexical and
value spaces. My preference is to define the lexical space as
all XML fragments which are valid according to a particular
content model, and the value space to be the canonical
XML serialization of that XML fragment.

Thus, the L2V (lexical to value) mapping is canonicalization,
and comparison of values is based on string equality of
canonicalized fragments.

One could also define the value space in terms of infosets,
but I'm not sure that that is necessarily a better approach.

> Also, this seems to bring back the "parseType='Literal' as
> CDATA section" thing, which is the main problem in proposal 1.

Yes and no.

For both proposal 1 and the revised proposal referenced above, 
rdf:parseType="Literal" acts like the #ANY content model,
which is simply not interpreted as expressing any RDF statements,
but is still well formed XML.

If it were CDATA, then you'd have to escape it even when 
serialized as element content, just as for attribute values.

There is, though, a special treatment of typed literals which
does exclude contextual scoping mechanisms such as xml:lang
in a similar fashion to a CDATA section, and that is triggered
by the presence of rdf:datatype -- in which case, the literal is
non-contextual and kept "uninfected" from xml:lang and the
like.

Patrick

Received on Tuesday, 15 July 2003 03:13:11 UTC