Re: a few comments about DTB

>>>> how about that the beginning of section 4.1:
>>>> "For each datatype a guard function is defined."
>>>
>>> Does that mean we impose guards and negative guards for *ALL* datatypes?
>>
>> I'm not sure what you mean with "impose".  We simply define the 
>> functions.
> 
> I mean: whenever oned defines a new datatype, you mean that 
> implementeing guards and negative guards have to be implemented as well?
> 
> I reformulated this slightly now.

Requiring implementing guards for datatypes is really a conformance 
issue, and the conformance statement currently in BLD does not require 
guards to be implemented for supported every datatype, and I think that 
is fine.
I do think that guards need to be defined for every datatype. If one 
wants to use these guards, one can do so.  But one can only share the 
rule sets that use of such guards with consumers that support the 
guards, which is fine, I think.

Best, Jos

> 
>>>>>> - section 4.3, casting:
>>>>>> The casting functions are under-defined:  1 It is unclear for 
>>>>>> which data
>>>>>> types these functions are defined.
>>>>>
>>>>> I improved this.
>>>>
>>>> I noticed that in section 4.3 there still a mention of "RIF 
>>>> supported datatype".
>>>
>>> see above.
>>
>> So, get rid of it! Deleting words is easy.
> 
> reformulated.
> 
>>>>>> 2 the reference to the table in section 17.1 seems to be 
>>>>>> incorrect.  The
>>>>>> table does not specify any conversions.  It actually specifies which
>>>>>> cast functions are defined, not how they are defined.  You can 
>>>>>> probably
>>>>>> use the table for defining which cast functions exist.
>>>>>> Then, the table only speaks about XML schema datatypes, which seems
>>>>>> insufficient for our purposes.
>>>>>
>>>>> I am not sure how to address this comment. I think as for the cases 
>>>>> not covered by the table, the restructureing which i did now fixes 
>>>>> this.
>>>>
>>>> Yes.
>>>>
>>>>> If you say that the conversion itself is not covered... well, all 
>>>>> these casts are explained in detail in the subsections of 17.1. so, 
>>>>> I could reword to "as shown in the table ... and defined in the 
>>>>> subsections ...
>>>>> but I definitly don't want to duplicate anything here.
>>>>
>>>> you do not need to redefine things, but you do need to include 
>>>> specific references. Plus, you need to say how the RIF casting 
>>>> functions are obtained from the xquery casting functions.  For 
>>>> example, the sections talk about raising errors, which is not 
>>>> supported in RIF.  Nonetheless, you need to say what happens in the 
>>>> RIF casting function if such an error is raised.
>>>> So, for each casting function, you need to carefully check what the 
>>>> relationship is between the intended RIF casting function and the 
>>>> x-query function and make sure your definition is a complete 
>>>> definition of the function.
>>>
>>> I need to rethink this... not dure whether I can address it before my 
>>> vacation (going to be from tomorrow until end of next week)... maybe 
>>> this can wait for the second WD?
>>
>> I guess it can wait.  But please include editor's notes saying that 
>> the functions are to be defined.
> 
> done.
> 
>>>>>> 3 you can probably use the text in section 17.1 to specify (part of)
>>>>>> some of the cast functions.  However, you do need to take care of the
>>>>>> non-XML schema casting and the handling of errors.
>>>>>
>>>>> precicely, that is why I think a reference to section 17.1 and the 
>>>>> improvements I did now are sufficient (at least for first public WD)
>>>>
>>>> The improvements are not sufficient, as I argued above.  If you want 
>>>> to go ahead and publish these incomplete definitions in the first 
>>>> public working draft, you should at least include an editor's note 
>>>> saying that these functions will be specified in more detail in a 
>>>> future version.
>>>
>>> Did so.
>>>
>>>>>> 4 rif:XMLLiteral -> rdf:XMLLiteral (in several places in the 
>>>>>> document)
>>>>>
>>>>> done
>>>>>
>>>>>> 5 conversion between IRIs and strings cannot be defined as a 
>>>>>> function.
>>>>>> It could be defined as a predicates.  Please recall the discussion 
>>>>>> and
>>>>>> the revised definition in [1].
>>>>>
>>>>> will do that next... this is how far I got today. attacking your 
>>>>> other mails hopefully over the week.
>>>>>
>>>>>> - I wonder what the justification is for just retaining the 
>>>>>> language in
>>>>>> the cast from text to string
>>>>>
>>>>> because you want to get the "pure" string out of it, disregarding 
>>>>> the lang tag... the lang tag can be extracted with func:lang.
>>>>
>>>> So why not an extraction function for the string part? 
>>>
>>> matter of taste...
>>>
>>>> Usually, when casting from one type to another, you don't want to 
>>>> lose information. For example, you don't want to cast a negative 
>>>> integer to a nonnegative integer by simply removing the negation, 
>>>> because you lose information.
>>>
>>> ... I find the former more intuitive, since I do not consider the 
>>> lang tag part of the string. We may vote over it, I think there are 
>>> arguments for both views.
>>
>> Please include an editor's note in the draft saying that the function 
>> is still under discussion.
> 
> done.
> 
>>>>>> - section 4.7: I don't really like the name of the function ("lang");
>>>>>
>>>>> I do. This is also used in SPARQL.
>>>>
>>>> I think built-in functions should all use the same naming convention.
>>>> Other opinions anyone ?
>>>
>>> If not, I would rather keep it.
>>
>> Please include an editor's note in the draft saying that the name is 
>> still under discussion.
> 
> done.
> 
> Axel
> 
>> best, Jos
>>
>>> Also see that I now chenged the subheadings in the document to better 
>>> reflect the origin of our built-ins.
>>>
>>> Thanks for the continuous comments! Helps a lot!
>>>
>>> Axel
>>>
>>>> Best, Jos
>>>>
>>>>>
>>>>>> this sounds more like the name of an attribute.  I would prefer using
>>>>>> the Xquery convention: lang-from-text
>>>>>>
>>>>>> Best, Jos
>>>>>>
>>>>>> [1] 
>>>>>> http://lists.w3.org/Archives/Public/public-rif-wg/2008Mar/0023.html
>>>>>> -- 
>>>>>> Jos de Bruijn            debruijn@inf.unibz.it
>>>>>> +390471016224         http://www.debruijn.net/
>>>>>> ----------------------------------------------
>>>>>> An expert is a person who has made all the
>>>>>> mistakes that can be made in a very narrow
>>>>>> field.
>>>>>>    - Niels Bohr
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
> 
> 

-- 
Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
----------------------------------------------
Public speaking is the art of diluting a two-
minute idea with a two-hour vocabulary.
   - Evan Esar

Received on Monday, 23 June 2008 11:49:53 UTC