Re: [DTB] ACTIONs 428 and 292 completed

Axel,
Some comments after the first quick pass.

0. The name of the section "Namespaces" is not good. It does not define
   any namespaces. It specifies compact uri prefixes used throughout the
   document. In BLD and FLD, the term namespace is used only to refer to
   the namespaces of some XML standards. Given the confusing history of
   using the term "namespace" for two different things, I think we should
   not even mention this term needlessly.

1. The semantics of builtins should be consistent with what is used in BLD
   and FLD.

2. There is no "error" element or an error truth value. Initially we
   decided not to use error truth values but use error elements. However,
   as I mentioned to you in an earlier email, even this special error value
   has semantic problems. BLD and FLD do not use such a special value and,
   in fact, there is no need for it (we cannot achieve with it more than
   what we can achieve without it).

   There is no need to keep so many ed notes "Shall we return an error or
   false on typing errors".  For predicates, returning an error is not an
   option, and instead of false we found a better solution (resolved at the
   f2f in Paris).

3. The stuff about symbol spaces should be copied (with appropriate
   modifications) from FLD to DTB. This is so that FLD-independent
   descriptions (such as the one in BLD) will not need to send the reader
   to the FLD document. Telling the reader to go and read parts of FLD
   might seem intimidating.

   Ditto with external schemas. The externals and symspaces are the only two
   things that need to be copied, I think.

   DTB should refer to FLD, but only as a source from which it borrows things
   like the symbol spaces, external schemas, etc.

4. Input and output value spaces should be described for all
   functions. Probably enough to use one or two sentences at the beginning of
   some sections. This is because a title like "Functions on Strings" does
   not tell everything. For instance, some such funcs return strings and
   other return integers.

   There should be a general statement as to what happens if an arg is
   outside of the domain.

5. Names of the sections are a bit odd. For instance, instead of Predicates
   on Numeric Values it would be better to say Numeric Predicates.

6. Would be nice to give small examples. One per function or one per group
   of functions.

7. Issue in sec 4.4.
   I agree that it is an issue, but saying that allowing polyadic symbols
   is syntactic sugar is a misrepresentation of the issue. A lot of
   things are syntactic sugar and early drafts of BLD allowed polyadic
   symbols. Then some members of this group went to the barricades and
   polyadic things became a history. Because of this, BLD goes into special
   troubles explaining what is well-formed and what is not.

   So, this is not an issue of syntactic sugar, but of what is allowed in
   BLD and, moreover, whether non-polyadic dialects are to be allowed in RIF.


	cheers
	  --michael  

    
> DTB is ready for review, slightly delayed:
> 
> http://www.w3.org/2005/rules/wiki/DTB
> 
> At least, it should be - although not officially part of the published 
> working drafts in this round - be stablilized to comply mostly with the 
> definitions in FLD and BLD concerning external schemas.
> 
> This also completes ACTION-292
> "Put links for each builtin to Xquery source URI"
> 
> best,
> Axel
> 
> -- 
> Dr. Axel Polleres, Digital Enterprise Research Institute (DERI)
> email: axel.polleres@deri.org  url: http://www.polleres.net/
> 
> rdfs:Resource owl:differentFrom xsd:anyURI .
> 
>

Received on Thursday, 17 April 2008 00:04:38 UTC