Re: DTB frozen and last changes

Jos de Bruijn wrote:
> Axel,
> 
> Did you read my email [1]?
> It seems only the first comment was taken into account.


- added pointers to mails where possible

 > Concerning the last editor's note in section 3.1: it was decided that
 > the value spaces of decimal and double are disjoint. ( I believe this
 > was a resolution in the last face-to-face )

- rephrased the respective Ed note, but didn't yet want to drop it, 
since I was unsure how to resolve it. I suggest to just reformulate it 
as an explanatory note to the example, what is open though is 
wher/whether we need references to XML Schema 1.1? We still reference 1.0.

- another issue is part of the resolution you are pointing at, it seems 
that it includes the addition of more namespaces and datatypes to DTB:

Added another Ed note in the beginning of section pointing to that 
resolution:
"Editor's Note: It was decided in the F2F12 resolutions that 
additionally datatypes xsd:nonNegativeInteger, xsd:anyURI, 
xsd:hexBinary, xsd:base64Binary are to be added to RIF Core. It seems we 
need to include them in DTB as well."

> There is still a number of problems with the definitions of the casts:
> - it is unclear what the word "castable" means. In fact, it is not used
> in the referenced specification. You should refer directly to the table
> in the specification and use the terminology used there (S/T, etc.)
> - what is an "intended domain"? Don't you mean "domain"?
> - the domain of a cast function X is the *union* of the value spaces of
> the datatypes for which casting to X is supported according to the table
> http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#casting-to-primitives-table
> [Please link directly to the table]. a value space includes all its
> subsets, so it's meaningless to talk about them.

  Do I understand right that
"the domain of a cast function X is the *union* of the value spaces of
the datatypes for which casting to X is supported according to the table 
http://www.w3.org/TR/2007/REC-xpath-functions-20070123/#casting-to-primitives-table
[Please link directly to the table]."
is your suggested rewording? I adopted that

> - the concept of some value being the "conversion of" another value is
> not defined in the mentioned section. In addition, there is no reason to
> be so imprecise in the mappings. Each cast function should refer to the
> precise location of the definition in the F&O spec.

I kind of prefer to keep that generically referring to section 17.1 
instead of the precise subsections there. Easier to maintain and in my 
opinion enough to find the respective definitions. Anyway, need to catch 
the flight now, we can talk about it further, also whether you have some 
better wording for "conversion".

thanks,

Axel

> Jos
> 
> [1] http://lists.w3.org/Archives/Public/public-rif-wg/2009Apr/0040.html
> 
> Axel Polleres wrote:
>> now for real: DTB is frozen... additional changes:
>>
>> 7) removed pred:text-equal, pred:text-less-than, ... analogously to
>> removing the resp. functions for xs:string.
>>
>>
>> 8) removed the two ed notes that jos identified as obsolete:
>>
>> Jos de Bruijn wrote:
>>> I believe the two editor's notes at the end of section 1 are obsolete.
>>
>> Axel
>>
>> Axel Polleres wrote:
>>> oops sorry, pressed "send" too early, actually I wanted to save the
>>> message. I am still doing some small changes, apologies for the
>>> confusion.
>>>
>>> Axel Polleres wrote:
>>>> The latest changes in DTB are mainly in terms of rdf:text:
>>>>
>>>> 1) Casting from rdf:text to xs:string is now included, a respective
>>>> editor's note in Section 3.2.9 on Casting to xs:string has been added.
>>>>
>>>>
>>>> The following old note is no longer needed, given the latest changes
>>>> in rdf:text:
>>>>
>>>> "Note: Since RIF implementations MAY choose to interpret
>>>> <tt>xs:string</tt> and its subtypes as subtypes of <tt>rdf:text</tt>
>>>> following Section 3.1 of
>>>> <nowiki>[</nowiki>[[#ref-rdf-text|RDF-TEXT]]], in such
>>>> implementations this cast function also serves for conversions to
>>>> <tt>rdf:text</tt>."
>>>>
>>>> 2) I needed to temporarily change the reference to rRDF-TEXT to the
>>>> wiki-doc, as the TR version is totally outdated.
>>>>
>>>> 3) I removed the Editor's notes on the example on xs:string vs rdf:text.
>>>> after isLiteralNotOfType (Section 3.1.2.2)
>>>>
>>>> Note: I am inquiring this again in the rdf:text-mailinglist, but my
>>>> understanding is that he value space of rdf:text now is a superset of
>>>> the value space of xs:string, such that automatically each value in
>>>> xs:string is also in rdf:text.
>>>>
>>>>
>>>>
>>>> Other, non-rdf-text related changes:
>>>>
>>>> 4) literal-not-equal was changed to literalNotIdentical
>>>>
>>>> 5) Ed note
>>>>
>>>> "Shouldn't we have a uniform naming convention here
>>>> <tt>pred:literal-equal</tt> vs. <tt>pred:isLiteralOfType</tt>, i.e.
>>>> dashes vs. CamelCase is not used uniformly."
>>>>
>>>> has been removed, since obsoleted.
>>>>
>>>> 6) The editor's note for isLiteralOfType now explicitly refers to
>>>> ISSUE-93.
>>>>
>>>> {{EdNote|text=Note that it is assumed the second argument of
>>>> isLiteralOfType to be a rif:iri at the moment, cf.
>>>> [http://www.w3.org/2005/rules/wg/track/issues/93 ISSUE-93].}}
>>>>
>>>>
>>>
>>
> 


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/

Received on Tuesday, 14 April 2009 09:09:56 UTC