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

Re: FW: XML literals

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Thu, 14 Aug 2003 09:01:06 +0100
Message-ID: <3F3B41C2.1070205@hplb.hpl.hp.com>
To: Martin Duerst <duerst@w3.org>
CC: w3c-rdfcore-wg@w3.org, w3c-i18n-ig@w3.org


I am happy with all your suggestions - I will produced updated text for 
tomorrow's RDF Core telecon.

I guess the following proposal would cover the process record:

[[
PROPOSE: accept the definition of rdf:XMLLiteral value space from

http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jul/0452

and action concepts editors to integrate it in the editors draft, using 
editorial discretion.
]]


The detailed text will be ready by the telecon if people prefer to vote on 
that.


Jeremy

Martin Duerst wrote:

> 
> Hello Jeremy,
> 
> As I already said in another context, this looks like a lot of
> good work and progress. Some more comments below.
> 
> 
> At 18:05 03/08/13 +0200, Jeremy Carroll wrote:
> 
> 
>> (Resend - forgot I18N first time)
>>
>>
>>
>> The main planks of Pat's text from
>>
>> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jul/0452
>>
>> seemed to get support at the RDF Core WG telecon on Friday, I was 
>> actioned
>> to move the conversation forward, and ensure that Martin and I18N were 
>> in on
>> it.
>> My understanding is that the main goal was to avoid any possibility of
>> confusing XMLLiteral with xsd:hexBinary as in Martin's test case.
>>
>> I also am trying to adequately address Patrick's concerns while changing
>> Pat's text as little as possible.
>>
>> Brian used the term "XML fragment" at the telecon, I am however sticking
>> with Pat's "XML value" because of the existence of
>>
>> http://www.w3.org/TR/xml-fragment
>>
>> which makes Brian's preferred term misleading.
>> I would be happy to consider other words for XML value.
>>
>> For completeness I also include stuff on the lexical space, since 
>> there was
>> some concern that the wording is not about Unicde strings ... and the 
>> word
>> "corresponding" ...
>>
>> I have numbered the notes for the sake of this e-mail, further discussion
>> below.
>>
>> Patrick - please indicate whether the last two notes (2,3) adequately
>> address your concerns. (3) ended up perhaps more geared towards some of
>> Martin's concerns.
>>
>> I ended up unclear as to whether note 2 was wanted by the WG or not.
>>
>> [[
>> The lexical space
>>   is the set of all strings which:
>>   + are well-balanced, self-contained XML data [XML];
> 
> 
> I think you can directly refer to production [43] of the
> XML specification (http://www.w3.org/TR/REC-xml#NT-content).
> This allows some stuff like CDATA sections that canonical
> XML will exclude, but otherwise is exactly what you need.
> 
> 
>>   + correspond  under [UTF-8] encoding to exclusive Canonical
>>     XML (with comments, with empty InclusiveNamespaces
>>     PrefixList ) [XML-XC14N];
> 
> 
> I think 'when encoded as [UTF-8]' would be slightly easier
> to understand than 'under [UTF-8] encoding'.
> 
> 
>>   + when embedded between an arbitrary XML start tag and an end tag
>>     correspond to a document conforming to XML Namespaces [XML-NS]
>>
>>
>> The value space is a set of entities, called XML values, which is:
>>   + disjoint from the lexical space
>>   + disjoint from the value space of any XML schema datatype 
>> [XML-SCHEMA2]
>>   + disjoint from the set of Unicode character strings [Unicode]
>>   + in 1:1 correspondence with the lexical space.
>>
>>
>>
>> The lexical-to-value mapping
>>    is a one-one mapping from the lexical space onto the value space,
>>    i.e. it is both injective and surjective.
>>
>>
>>
>> Note (1): Not all lexical forms of this datatype are compliant with 
>> XML 1.1
>> [XML 1.1]. If compliance with XML 1.1 is desired, then only those that 
>> are
>> fully normalized according to XML 1.1 should be used.
>>
>> Note (2): XML values can be thought of as the [XML Infoset] or
>> the [XPath] nodeset corresponding to the lexical form, with an 
>> appropriate
>> equality function.
>>
>> Note (3): RDF applications may use additional equivalence relations, 
>> such as
>> that which relates an xsd:string with an rdf:XMLLiteral corresponding 
>> to a
>> single text node of the same string.
>>
>> ]]
>>
>>
>> I seem to recall concern about putting too much into notes.
> 
> 
> Some people don't like notes. But they often help understand
> a spec better, and we all have made experiences about how not
> understanding a spec (or understanding it differently) has hurt us.
> 
> 
>> Either the stuff
>> is sufficiently important to go into the design, or it isn't.
>>
>> This may be sufficient to kill notes (2) and (3). I am reluctant to drop
>> note (1) since the RDF specs have largely followed charmod on NFC 
>> which puts
>> us into a somewhat anomolous position between XML 1.0 and XML 1.1 ...
> 
> 
> I'm confused here. Graham said that RDF allowed control characters,
> but XML 1.1 doesn't, and I showed him that it did. But XML 1.0
> doesn't.
> 
> 
>> If the notes add clarity then it is probably best to keep them.
> 
> 
> I think both notes add clarity. From an i18n viewpoint, note (3)
> is definitely helpful. For XML people, note (2) will be helpful,
> although it may be better to change 'can' to 'may', i.e.
> "XML values may be thought of as...". But that's a minor detail.
> 
> 
> Regards,    Martin.
> 
Received on Thursday, 14 August 2003 04:03:57 EDT

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