Re: RIF lists question referring to ourt last telecon discussion

> Started to clean up DTB wrt. List functions and predicates... cf.  
> ACTION-920
> 
> Question: Is
> 
>   External( pred: is-list( List ( 1 | 2 ) ) )
> 
> true or false or undefined? From the current informal definition this  
> is not clear.
> 
> I adapted the definition of
>    http://www.w3.org/2005/rules/wiki/DTB#pred:is-list
> assuming the former.
> Further, I added the following examples to the definition of is-list  
> in DTB:
> 
>     is-list(List(0 1 2 | List(3 4))) = True
>     is-list(List(1 | 2)) = True

Sounds good, thanks.

> BTW, this is not RIF syntax, so the examples for lists in the document  
> need to be
> in proper RIF presentation syntax,  ie. instead it should be:
> 
>    External(pred:is-list(List(0 1 2 | List(3 4)))) will evaluate to t  
> in any interpretation.
>    External(pred:is-list(List(1 | 2))) will evaluate to t in any  
> interpretation.
> 
> 
> I am not sure whether I manage to clean up all list functions, but I  
> think we cannot have
> examples in the document which aren't valid for any syntax we support,  
> so at least the examples should be cleaned up.

Since the only syntax we DO support (across all of RIF) us the XML, it
seems to me that in any given context, authors are free to use whichever
ad hoc RIF PS seems most clear.  In this case, I can see adding a note,
maybe with an example, explaining that of course in the XML, an
<External> would be needed.  I wouldn't formally object to someone
rewriting all the examples as you say, but to me it seems like a bad
idea, making the document harder to read with no real benefit.

> Given ambiguities of the informal mappings like these further convinces  
> me that it we
> probably don't want the informal mappings in the spec. Opinions?
> (I am still not sure how far I get with the cleaning...)

I think 9 out of 10 readers will find the informal mappings more useful
than any formal ones, and given the history of software engineering I'm
highly doubtful the formal mappings will be correct.  (They are
uncheckable pseudo-code for implementations.  To me, that seems worse
than defining these via a reference implementation, since it can't even
be tested by machine.)

    - s

Received on Sunday, 20 September 2009 15:19:01 UTC