W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > July 2003

XMLLiteral (was Re: call for agenda items)

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Wed, 16 Jul 2003 11:08:17 +0100
Message-ID: <3F152411.1080101@hplb.hpl.hp.com>
To: Patrick Stickler <patrick.stickler@nokia.com>
CC: ext Brian McBride <bwm@hplb.hpl.hp.com>, rdf core <w3c-rdfcore-wg@w3.org>, Martin Duerst <duerst@w3.org>, w3c-i18n-ig@w3.org

(Back from hols - hope not repeating what has already been said.)

Patrick Stickler wrote:

> Discussion of the refinement to literal handling, capturing the X and G
> views
> (contextual vs. non-contextual literals) as outlined in
> 
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jul/0165.html
> 
> Providing the benefits:
> 
> 1. XML literals can be encoded as contextual (plain) or non-contextual
> (typed).
> 
> 2. Allows contextual XML literals to have language tag associated, providing
>     consistent treatment of language qualification for all contextual
> literals, plain or XML.
> 
> 3. Removes special distinction in RDF graph between plain and XML literals.
> 
> 4. Allows complex typed literals (e.g. xhtml:table) to be serialized as XML.
> 
> 5. Only requires tweaks to RDF/XML syntax and RDF/XML to graph mapping.
> 
> Benefits #1 & #2 directly address concerns/wishes (as I've understood them)
> expressed
> by Martin and I18N WG (albeit not all of them) while still addressing the
> concerns/needs
> of those wishing to use the RDF Datatyping machinery (conveniently) for XML
> literals.
> 
> Benefit #3 addresses earlier concerns by TimBL about an artificial
> distinction or special
> treatment for XML literals separate from plain literals which breaks
> layering.
> (c.f. TimBLs comments:
> http://www.w3.org/2002/07/29-rdfcadm-tbl.html#xtocid103643)
> 
> Benefit #4 makes RDF more convenient for managing XML fragments with
> explicit typing.
> 
> Benefit #5 addresses the needs of the RDF Core WG to get things wrapped up
> without
> major rework.
> 
> --
> 
> While I think it has been agreed that there are no showstoppers in the
> present design,
> I have difficulty dismissing the view that the above minor changes are
> warranted.
> 

As I understand the proposal we would have:

<rdf:Description>
   <eg:prop rdf:parseType="Literal"><em></em></eg:prop>
</rdf:Description>


<rdf:Description>
   <eg:prop>&lt;em>&lt;/em></eg:prop>
</rdf:Description>

are alternative serializations of the same triple.

I think this is a substantial step backward from an I18N or an RDF point of 
view or both.

The problem is that from the G point of view there is simply a langstring 
in the graph. Whether or not the markup is intended as part of that 
langstring is not indicated. Martin gave a long list of examples in which 
knowing whether we are quoting or not matters.

The result of Patrick's proposal is that some RDF applications will take 
the view that the langstrings in the graph need to be escaped before 
serializing in XML, some will take the view that they do not need to be 
escaped before serializing, some will take the view that they only need 
escaping if they are not exc-c14n-xml.

This will lead to an interoperability nightmare on precisely the features 
of RDF that we are discussing, which, as Martin has pointed out, are needed 
for I18N.

All proposals that have ever been approved by RDF Core to get as far as at 
least an editors draft have had some means of distinguishing embedded XML 
from other literals. Without this different applications will make 
different decisions, some taking a G view some an X view.

Jeremy

(My summary from reading the threads seems to be the RDF Core decision is 
not nice, but there are no show stoppers, and nothing indisputably better 
on the table).
Received on Wednesday, 16 July 2003 06:09:02 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:58:45 EDT