- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Tue, 15 Jul 2003 10:12:38 +0300
- To: <bwm@hplb.hpl.hp.com>, "ext Martin Duerst" <duerst@w3.org>
- Cc: <w3c-rdfcore-wg@w3.org>, <w3c-i18n-ig@w3.org>
----- 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. 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:14:00 UTC