AW: DTB reviews and todos

Thanks Axel. 

I quickly checked the implementations of the editors note which we discussed in the last telecon and everything is fine. 

The schema for func:except seems to be wrong - you probably meant ?list1 \ ?list2

Further comments inline in your reply below.

-Adrian



-----Ursprüngliche Nachricht-----
Von: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] Im Auftrag von Axel Polleres
Gesendet: Montag, 18. Mai 2009 21:21
An: Public-Rif-Wg (E-mail)
Betreff: DTB reviews and todos

Apart from Michael's mail [1] and Adrian's preliminary review [2] I 
didn't get updated reviews yet.

They have both been addressed, some maybe need discussion:

> Section 2.2.
> 
> “The semantics of external terms in RIF-FLD and RIF-BLD is defined using
> two mappings: Iexternal and Itruth ο Iexternal….” 
> 
> What about RIF Core and RIF PRD. The condition language of PRD and the newly
> introduced external print built-in use this semantics from DTB (FLD) – so
> they should be mentioned as well.

For the moment, I changed this to:

"The semantics of external terms is defined using
two mappings: Iexternal and Itruth ο Iexternal…."

does that do the trick?


Adrian: Yes - it keeps the "door" open for Core and PRD


> “RIF supports identity for typed literals through the "=" predicate in all
> dialects that extend RIF-CORE. Identity for typed literals is defined as
> being the same point in the value space for that type.”
> 
> That would disallow future order-sorted typed RIF dialects to be extensions
> of RIF Core – literals are equal if they belong to the same sort (type) or
> a sub-type.

I don't see that this is prevented. The identity notion can be extended 
for those, but the sentence still holds, doesn't it?
I left that unchanged.

Adrian: Yes, reading it twice you’re a right since it explicitly refers to the type.


> 3.6.1.1 func:not
> Maybe we should add a sentence about the difference of this not function
> built-in and negation as e.g. in PRD to make it explicit – but it is also
> fine as it 

I left it as it is.

Adrian: Ok

> Maybe a general “RIF DTB Extensibility” section at the end could be
> helpful which describes how future RIF dialects would extend RIF DTB and how
> user-defined functions and built-ins can be defined with respect to the
> “normative” DTB built-ins.

Good idea, but I not if we want to go to LC tomorrow. otherwise I am 
open to discuss this. Anyways the necessary ingredients are there in
DTB. We could mention PRD as an example of a dialect that extends the 
coheent set of external schemata of DTB.

Adrian: right, time is running - ok


Here two more TODOs which are less clear:

* Speaking of "primitive datatypes" should be avoided

We call our datatypes "primitive" but this is not in compliance with
  http://www.w3.org/TR/xmlschema11-2/#dt-primitive
since we also use "primitive" for what are actually "ordinary" datatypes 
following XSD. I suggest we just speak about datatypes.


Adrian: what about "simple datatypes"?


* in my BLD review, I suggested that the Base Directive should refer to 
*absolute* iri:

     "where iri is a unicode string in the form of an *absolute* IRI
         [RFC-3987]."

Adrian: agree

  if we agree on that, then it also should be adopted in DTB.

Axel



1. http://lists.w3.org/Archives/Public/public-rif-wg/2009May/0135.html
2. http://lists.w3.org/Archives/Public/public-rif-wg/2009May/0101.html

-- 
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, 19 May 2009 11:11:07 UTC