Re: Denotation of XMLLiterals: poll

* Brian McBride <bwm@hplb.hpl.hp.com> [2003-08-06 12:29+0100]
> 
> It seems that there is some concern about XMLLiterals denoting octet 
> sequences.  As I understand things, RDFCore doesn't feel strongly that 
> the denotation MUST be octet sequences.  Pat has layed what we really 
> care about in:
> 
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jul/0452.html

I'd missed that 1st time around. Nice summary.

> 
> I suggest we accept Pat's suggestion and reconsider the denotation of 
> XMLLiterals.  I have seen three suggestions, as I recall:
> 
>  A) be a bit vague about XMLLiterals really are - just define their 
> essential properties

I can live with this, something along lines of 
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jul/0452.html

>  B) have them denote XPATH nodesets

Slight nervousness - which version of XPath?
http://www.w3.org/TR/xpath20/ isn't done yet, but when it is, folk might
be dissapointed if RDFCore has just gone to REC with a normative
reference to the ageing 1.0 Xpath.
> 
>  C) have them denote a pair (uri, lex form), where uri is the uri of 
> rdf:XMLLiteral.
> 
> Concern has been expressed about A being to vague.  Others have 
> responded saying thats normal - integers are defined in terms of their 
> properties.
> 
> Concern has been expressed that XPATH nodesets are too vague, we don't 
> really know that they are and are thus no better than A, but are in some 
> way worse.  Cannonicalization does define an equality relation on them

Some sympathy there.
> 
> I have heard a private concern expressed about C, that if we did that, 
> shouldn't we treat all datatypes that way.  Further, that this does 
> guarantee that there are no other ways of denoting the same pair with 
> another, posibly user defined datatype.
> 
> How do we choose?  If you have a preference and rationale, it would be 
> good hear it.

I have no strong view (except lately I keep running into use cases for 
properties-of-literals, but that I guess is water under the bridge...).

Dan