Re: I18N Issue alternative: collapsing plain and xml literals

At 17:15 09/09/03 +0100, Brian McBride wrote:
>Graham Klyne wrote:
>>Brian,
>>As I understand it, this proposal
>
>Its not a proposal - at least I'm not making a proposal.

OK, I misinterpreted you.  So, to be clear, what follows is on the 
understanding that we are exploring alternative designs, not proposing them...

(I have raised non-exploratory points arising in separate messages.)

>  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.

Ah, this depends on different understanding of the current RDF/XML 
syntax;  I've raised this as an issue for clarification in a separate message.

[...]

>>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.

Not quite:  treat all literals as plain text, which MAY be used to encode 
XML.  That's the "different way round".  Yours, I think, is to treat all 
literals as XML which MAY be used to encode plain text.

>How do we distinguish between text and markup e.g. how to I represent the 
>book title

I don't.  At least, not as part of the literal itself.  The property used 
would determine that.

So, considering:

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

the property eg:title would relate the plain text strings used above to the 
rich text you described:

>   The <b> Element Considered Harmful
>
>where "<b>" is in bold?

However, a different property:

   _:a eg:rel "foo < big" .

might relate the plain text given to an expression that performs a comparison.

[...]

>Hmmm, but you would allow "<" as a legal rdf literal lexical form and the 
>other design didn't.

Yes.  I have always understood RDF to be this way.

Indeed, I have real RDF (N3) data that contains *HTML* (not XML) markup in 
literal values.  I'd be most surprised if I'm alone in this.

>   That means we can't treat all rdf literals as xml.  So how do we know 
> when they are and when they are not?

See above.  There's no absolute rule, and I don't see why there should be.

>>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.

Just a little ;-)

#g


------------
Graham Klyne
GK@NineByNine.org

Received on Wednesday, 10 September 2003 04:07:44 UTC