Re: I18N Issue alternative: collapsing plain and xml literals

Graham Klyne wrote:
> Brian,
> 
> As I understand it, this proposal

Its not a proposal - at least I'm not making a proposal.

  could break existing RDF data.  E.g.
> 
>   <rdf:Description>
>     <eg:prop>foo &lt; bar</eg:prop>
>   </rdf:Description>
> 
> would no longer be valid RDF.  

It would remain legal rdf/xml.

Currently, I think it describes the graph:
> 
>   _:a eg:prop "foo < bar" .

with the design I described it would describe the graph

   _:a eg:prop "foo &lt; bar" .

> 
> [[[Hmmm... The RDF validator service says it maps to:
> 
>   _:a eg:prop "foo &lt; bar" .

Well, there's a coincidence :)

> 
> That doesn't seem right to me.  Did we really decode that?  If I add the 
> parsetype=literal, I get the same thing with the XML literal datatype 
> added.  RDF validator bug report submitted.]]]
> 
> A similar proposal I have is to make the effect of parseType=Literal 
> purely syntactic, in that it modifies the handling of literal test in 
> RDF/XML, so that '&' and tags are effectively uninterpreted in the 
> translation to graph form.  (I had thought of proposing something 
> similar earlier, but was wary of adding more strands to the debate, but 
> now we're there...)
> 
> Then:
> 
> <rdf:Description>
>   <eg:prop>foo &lt;br /&gt; bar</eg:prop>
> </rdf:Description
> 
> parses to:
> 
>   _:a eg:prop "foo <br /> bar" .
> 
> and
> 
>   <rdf:Description>
>     <eg:prop rdf:parseType="Literal"><br /></eg:prop>
>   </rdf:Description>
> 
> parses to:
> 
>   _:a eg:prop "foo <br></br> bar" .

Interesting - similar idea - treat all literals as XML but you've got it 
a different way round somehow.  How do we distinguish between text and 
markup e.g. how to I represent the book title

   The <b> Element Considered Harmful

where "<b>" is in bold?

   _:a eg:prop "The <b>&lt;b&gt;</b> Element Considered Harmful" .

which could be written in rdf/xml as

   <rdf:Description>
     <eg:prop>The &lt;b&gt;&amp;lt;b&amp;gt;&lt;/b&gt Element...
   </rdf:Description>

or

   <rdf:Description>
     <eg:prop rdf:parseType="Literal">
       The <b>&lt;b&gt;</b> Element Considered Harmful
     </eg:prop>
   </rdf:Description>

Hmmm, but you would allow "<" as a legal rdf literal lexical form and 
the other design didn't.  That means we can't treat all rdf literals as 
xml.  So how do we know when they are and when they are not?

> 
> I think there remains a question:  can parseType=Literal be used in 
> conjunction with rdf:datatype=...?

Not in the design I described, but in yours ...

    I see no reason why not.  Then the
> current functionality of XML literals is possible without making it part 
> of the RDF core specification;  e.g.
> 
>   <eg:prop rdf:parseType="Literal" rdf:datatype="foo:XMLLiteral">
>      The <em>best</em> solution?
>   </eg:prop>
> 
> (Note:  I expect that rdf:datatype continues to ignore language 
> information, so the above example would not be sensitive to language 
> tagging.)
> 
> I think this approach has similar advantages to what you propose, 
> without some of the disadvantages, also separates XML syntax issues from 
> datatype issues, which I think is a distinct improvement, and remains 
> fully backward compatible with (my understanding of) existing RDF.

The backward compatibility is certainly a plus.


Brian

Received on Tuesday, 9 September 2003 15:36:05 UTC