W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2005

Re: layout changes in operator mapping and descriptions

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Sat, 22 Oct 2005 20:00:25 +0100
Message-ID: <435A8C49.3060300@hp.com>
To: Eric Prud'hommeaux <eric@w3.org>
Cc: public-rdf-dawg@w3.org

== Signatures

Putting in the complete syntax signature in the description is a big 
improvement.  It makes the section standalone as a reference for that 
function/operator.

I didn't find the alternative form in "11.2.3.10 sop:RDFterm-equal" so useful 
but leaving in the syntax form as well is good.

== Operator Table

The new table layout gets round the number of arguments problem which does get 
in the way currently.  Grouping by function is more reference-like though.

Suggestion: have one table and have a single column for arguments then have 
1,2 or 3 in that column as needed.  Sort of a mixture of the new layout and old.


== Other 1:

Some mention of the error handling in sop:logical-or sop:logical-and sections 
(11.2.3.8 and 11.2.3.9) might help - again, to make these a

Other 3:

This is an observation and unrelated to the new format. I found in 11.1.1

"""
XML Schema defines a set of types derived from decimal: integer; 
nonPositiveInteger; negativeInteger; long; int; short; byte; 
nonNegativeInteger; unsignedLong; unsignedInt; unsignedShort; unsignedByte and 
positiveInteger. These are all treated as decimals for arithmetic operations 
in FILTERs. SPARQL does not specifically require integrity checks on derived 
subtypes.
"""

I agree it does not lead to an observable difference (because we have only one 
version of divide) but the language is different in F&O where it says "integer 
+ integer => integer", not decimal.

Second table -
http://www.w3.org/TR/xpath-functions/#op.numeric

If a custom function were to provide idiv, op:numeric-integer-divide, then the 
difference would observable because the types of input affect the value out.

Hmm - that is at odds with the principle that SPARQL operates on values. 1/2 
should not depend on whether it's "1"^^xsd:integer or "1"^^xsd:double (in the 
presence of D-entailment at least).

	Andy

Eric Prud'hommeaux wrote:
> I created http://www.w3.org/2005/10/rq23-cmp for folks to look at and
> say "i like" or "i don't like".
> 
>   Operator Mapping Table [OPS] -- split by number of args
> 
>   Function definitions -- changed introductory example to look like a
>                           function prototype. ex. isBound [BND]
> 
>                           changed descriptive text to match argument
> 			  identifiers in the prototype. [LNG]
> 
>                           enumerated all legal argument types in the
> 			  function descriptions. [LNG]
> 
> The function description for sop:RDFterm-equal has three prototype
> styles at the top. I prefer the middle (and used it elsewhere) but
> I'm anxious to hear what others think, or if they have variations.
> 
> If you like, or don't reply, I'll commit this in rq23/Overview.html
> 
> [OPS] http://www.w3.org/2005/10/rq23-cmp#OperatorMapping
> [BND] http://www.w3.org/2005/10/rq23-cmp#func-isBound
> [LNG] http://www.w3.org/2005/10/rq23-cmp#func-lang
Received on Saturday, 22 October 2005 19:00:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:24 GMT