Re: A possible structure of the datatype system for OWL 2 (related to ISSUE-126)

>> 3. Impose explicit rounding rules above and beyond IEEE-754. This
>> would break every floating point implementation in existence. I would
>> encourage Oxford to object to such a model, and I can't imagine  
>> such a
>> proposal passing a vote of the AC.
>
> Would mandating the rounding algorithm remove the ambiguity?

I believe so: it is possible to declare that the conversion from  
decimal to floating-point must be "correct" by IEEE-754 standards in  
all cases, and not just for those values within the range I described.

Although that approach is coherent, I think it would be wildly  
impractical, as implementation would be incredibly difficult.

>> Other suggestions?
>
> If we can define, as you have above, the circumstances in which  
> problems
> become visible, those circumstances should be documented in some user
> facing document.

I agree that it should be documented, although considering the extreme  
rarity of the problem I don't think it's appropriate for introductory  
or tutorial documentation. (I don't think it's necessary to raise the  
issue in the OWL Guide, for example.)

One very annoying consequence is that any language in the OWL spec  
which claims that any OWL document is consistent (or not) in all  
interpretations will not be strictly true. We may need to revisit the  
notion of documents which include only unambiguous values, but only  
with respect to qualifying the language of the final specification. I  
think it's clear that conformant implementations should be required to  
support `xsd:float` constants of all types, but can map the decimal  
representations to values in any XSchema-(and thus IEEE-754-)compliant  
manner.

Does the WG have a mechanism for keeping a list of such issues to  
resolve in final language? (There was discussion on the telecon of a  
similar situation with MUST/SHOULD/MAY.)

-rob