Re: Issue jsr-118 (global datatyping)

At 16:25 02/04/2003 +0100, Graham Klyne wrote:

>Er, how did this issue end up being assigned to concepts?
>
>Anyway, here's a proposed resolution for discussion:

Whilest it starts well, I'm uncomfortable with this proposal.  It feels 
like we are telling cc/pp folks how to do their job, which is not our place 
to do.

The facts here are:

   o we have conflicting requirements which we were unable to find a 
compromise on

   o we have not had strong pushback from the community on the choice we 
have made.

   o Mark (I beleive speaking as jsr-188) has indicated that a *syntactic* 
solution would be acceptable to him - so he is saying they don't need full 
long range datatyping

I suggest a response along the lines of:

   o the WG has considerable sympathy with this request
   o we tried real hard, but couldn't reconcile this with other requirements
   o given this was a very difficult issue, we are aware that we can't 
satisfy everybody
   o given the lack of strong negative feedback at last call, the WG 
believe that the community would rather we proceed with the proposed 
solution, than go back and try again, with the consequent delays.
   o we note marks comment that a syntactic solution would be acceptable 
and encourage cc/pp to investigate such solutions, which might have general 
applicability.

     http://lists.w3.org/Archives/Public/www-rdf-comments/2003JanMar/0570.html

Brian


>Rejected, or maybe postponed.
>
>[[
>We have much sympathy with this request.  But the working group spent much 
>time exploring options to allow global datatyping of the kind requested 
>here, and were unable to find a solution that allowed this and also 
>preserved other strongly-desired features of RDF.  It might be possible to 
>devise an alternative syntax-based approach to global datatyping, but I 
>think even that would not fully capture the goals of CC/PP here, to 
>express capability profile feature types in a schema separately from 
>on-the-wire profiles.
>
>The current version of CC/PP formally treats all attributes as textual 
>values (i.e. plain literals in RDFcore parlance).  The global datatyping 
>could be achieved for CC/PP applications by continuing to formally treat 
>all CC/PP attributes as textual values and:
>(a) using range constraints to limit the allowed lexical values, and
>(b) building the lexical-to-value mapping into the semantics of the CC/PP 
>attribute properties.
>
>(a) would require some URIs to be designated to denote classes for the 
>lexical space of the datatypes used.  Currently, CC/PP uses its own URIs 
>for datatypes, so this would be easily accommodated.  In practical terms, 
>I see no changes to current CC/PP applications required by this 
>change:  what is described above is a formal device to make CC/PP as 
>currently defined be consistent with the current semantic framework.
>
>The downside of this approach is that it is a non-standard approach to 
>using literals to indicate datatype values, and it may add some complexity 
>if and when future developments of CC/PP require to express comparisons 
>between CC/PP attribute values and datatype values from other RDF descriptions.
>]]
>
>Note to WG:  the suggested CC/PP approach is basically a strategy for 
>implementing CC/PP under the old datatyping proposal 'S', ignoring the new 
>datatyping facilities.
>
>#g
>
>
>-------------------
>Graham Klyne
><GK@NineByNine.org>
>PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

Received on Thursday, 3 April 2003 04:48:20 UTC