RE: typed literals and language tags - ugly parade

> -----Original Message-----
> From: ext Jeremy Carroll [mailto:jjc@hplb.hpl.hp.com]
> Sent: 09 May, 2003 12:41
> To: Jeremy Carroll; w3c-rdfcore-wg@w3.org
> Subject: RE: typed literals and language tags - ugly parade
> 
> 
> 
> 
> This message summarises the disadvantages of each proposal 
> (and the fifth option of doing nothing).
> 
> Doing nothing
> =============
> 
> This leaves a language tag in the syntax of literals such as 
> "2"@en^^xsd:int, which is (a) explicitly meaningless and (b) 
> without rationale.
> This is likely to lead to user and implementor confusion and 
> possible interoperability problems.
> 
> > Option 1:
> > 
> > PROPOSE
> >    XML Literals are as in the working drafts prior to 
> November 2002, in 
> > which it was not a typed literal, but a special sort of literal,
> > with the changes made as a result of the reagle-01 and 
> reagle-02 issues. 
> > (i,e. exc-c14n performed in the syntax document)
> >    Typed literals to exclude the language tag in the 
> abstract syntax.
> > 
> > editors of Syntax, Concepts, Test and Semantics actioned to come 
> > back with 
> > text, based on current editors drafts, and last version before we 
> > switched 
> > to the rdf:XMLLiteral type, for the group approval.
> 
> This design was negatively received in earlier drafts.
> 
> With XMLLiteral as a distinct thing from typed literals then 
> more implementors may choose not to implement it, causing 
> interoperability problems between systems that support XML 
> Literal, and ones that don't.

I would only accept this argument in relation to choosing
option 1 over option 4. As for choosing option 1 over doing
nothing, or option 2 or 3, I think that the implementational
burden is less with this option so would make life easier
for implementors.

Even though option 2 or 3 have fewer types of literals, treating
XML literals as typed literals, the work required to keep sense
of the lang tags is I think greater.

Ugg... sorry, I'm probably making this too complicated ;-)

 
> > > Option 2:
> > > Literals can have both a type and a language tag if and only if
> > > the type is
> > > rdf:XMLLiteral, otherwise unchanged.
> > 
> > 
> > PROPOSE
> >   Concepts is changed to say that a literal can only have 
> both a datatype
> > and a language tag when the datatype is rdf:XMLLiteral.
> >   Other editors to make consequential changes.
> > 
> 
> This excerbates rdf:XMLLiteral being an anomolous datatype, 
> in that the syntax is anomolous as well as the semantics.
> This then has similar dangers  (to option 1) of a schism 
> between implementors who can be bothered with it, and those who can't.

Yep. Goes from bad to worse, IMO.

> > Option 3:
> > PROPOSE
> >    Typed literals, including XML Literal, to exclude the 
> language tag in 
> > the abstract syntax.
> >    XML Literals to be refactored by deleting the 
> <rdf-wrapper> text from 
> > concepts and putting it into syntax (probably in para 7.2.17).
> >    Add the following implementation note (or similar) to syntax.
> >    Change NTriples in test cases to show explicit 
> <rdf-wrapper> for all 
> > XMLLiterals.
> 
> This is ugly in the syntax, and the <rdf-wrapper> hack 
> becomes increasingly in-your-face. There is also a danger of 
> non-backward interoperability with people who used to generate
> 
> <html>
> <head></head>
> <body>
> <p>This comes from RDF</p>
> </body>
> </html>
> Now getting
> <html>
> <head></head>
> <body>
> <p><rdf-wrapper>This comes from RDF</rdf-wrapper></p>
> </body>
> </html>
>
> > > Option 4:
> > > Language tag is simply dropped from all typed literals including
> > > rdf:XMLLiteral
> > >
> 
> This makes it awkward to embed xhtml inside RDF maintaining 
> language information. Since this is an important use case we 
> probably need to:
> 1) make sure that examples are included in syntax or the 
> primer showing use of 
> <span xml:lang="en"> to include langauge information inside a literal.
> 2) give clear warnings
> 3) alert I18N

Right.

Patrick

Received on Friday, 9 May 2003 07:28:33 UTC