Re: XML Schema is untidy (was RE: type test case)

Graham,

I think it's an excellent summary, thanks! One correction: the new 
proposal should be attributed to Guha 
(http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Jul/0199.html), 
not me.

Sergey


Graham Klyne wrote:

> 
> At 12:18 PM 8/8/02 +0300, Patrick.Stickler@nokia.com wrote:
> 
>> > It appears that community feedback is that that's exactly
>> > what we ought
>> > to be doing (for a small set of datatypes)
>>
>> I didn't see any substantial feedback suggesting this.
>> A few outspoken respondents does not constitute an
>> overwhelming concensus of community feedback.
>>
>> Furthermore, the inquiry to the community had nothing to
>> do with this, and the proposals reflected in that inquiry
>> provide *full* support for all XML Schema datatypes.
> 
> 
> I think it's worth recapping how we got to the current point of debate.
> 
> This is, of course, a personal interpretation and I'd be happy to be 
> corrected by others.
> 
> Following Brian's question to the wider community, it seemed clear that 
> we were *not* going to get a clear answer to the point we were trying to 
> resolve.  To my view, and I think to that of others, there is no clear 
> consensus concerning the tidy vs untidy question.
> 
> Thus, we were in danger of creating a recommendation about a matter 
> whose ramifications are not adequately understood.  In such 
> circumstances, it is better to be less ambitious -- better to leave 
> something (clearly) unspecified than wrongly specified.
> 
> Next, it seemed that there *is* consensus about the meaning of:
> 
>     :Jenny :age _:x .
>     _:x type:integer "10" .
> 
> i.e. the so-called "local idiom".  It is the global idiom that is 
> proving difficult to pin down.  Maybe, we are chasing a chimera and 
> shouldn't even try to realize that (global datatyping) form, however 
> attractive its attributes may appear.
> 
> Further, this "local idiom" doesn't require any change to the basic RDF 
> model theory, (other than possibly to note the data type mapping is 
> fixed separately from the rest of the interpretion).
> 
> At the last teleconference, it was pointed out (and generally accepted) 
> that to publish an RDF recommendation without a good account of how to 
> deal with something as pervasive as numbers would be a grave disservice 
> to the RDF community as a whole.
> 
> This is roughly the point at which you have rejoined the debate, at a 
> time when the choice between the triple-based local idiom, and extending 
> the notion of literals to include well-defined denotations of numbers 
> (and maybe other values) as well as strings, has not been finally nailed 
> down.  (But I think the group is leaning toward the notion of extended 
> literals -- that's the essence of Sergey's proposal.)
> 
>> The WG has *agreed* that any deviations from the stake-in-the-ground
>> proposal would be motivated by clear technical and practical
>> considerations -- i.e. fatal flaws or errors in the proposal.
> 
> 
> This is a change of tack from what we were trying to do previously, and 
> one which is motivated by a very strong technical and practical 
> considerations:  without cutting back the scope of the problem in this 
> way, it is likely that this working group will never finish.  More than 
> anything now, we need to finish.
> 
> Yes, there are details to iron out, but compared with what we were 
> trying to do they are small details.  If we get them wrong, the result 
> will be some small inconvenience rather than possible severe damage to 
> the whole RDF framework.
> 
> And I think the "stake in the ground" still remains:  I think nothing 
> we're trying to do now is inconsistent with the stake-in-ground 
> principles, but we are trying to do less so the full reach of that stake 
> may not be needed.
> 
> #g
> -- 
> 
> PS: looking back, I suspect Brian foresaw much of this back in Cannes, 
> when he suggested concentrating on the "local idiom".
> 
> 
> 
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
> 
>

Received on Friday, 9 August 2002 06:26:13 UTC