Re: Issue jsr-118 (global datatyping)

This is fine with me.

(I shall cease further discussion of my earlier proposal.)

#g
--

At 10:49 03/04/2003 +0100, Brian McBride wrote:

>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
>
>..
>.

-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

Received on Thursday, 3 April 2003 13:43:42 UTC