Re: Is this really it? (was: I18N response draft3)

At 11:36 29/09/03 +0100, Jeremy Carroll wrote:
>I agree that these are possible weaknesses, I think the schedule issue is 
>an important one. Please suggest improvements - possibly to do with use of 
>this document, and a separate rebuttal that consists of
>a) the blow-by-blow account I added in today's draft
>b) discussion of wider issues such as schedule and no compelling reason 
>for delay

Hmm... I should have expected this (which is a quite proper and reasonable 
response).

Rather than attempt a new drafting, what I'm going to do here is suggest an 
outline drawing upon existing material that I hope might present the 
information in a way that more closely reflects (my perception of) this 
group's reasons for not acceding.

[[
Why we didn't accept I18N's objection to the design of XML literals

1. Review status of the WG, noting that we're long overdue, losing 
participation, and that the I18N desideratum for "seamless plain and XML 
literals" was only articulated well after the end of LC1.  This might use 
material from my earlier message [1].

2. point by point response to I18 concerns, per Jeremy's message [2], in 
particular the new final section of [3].

2a. note that the WG has wrestled long and hard with datatype issues (which 
are closely related, and in particular that the handling of both XML and 
language tags is intimately bound up with the MT for literals).  Due to 
conflicting desiderata, there are no easy fixes that don't require a lot of 
reworking.  [Cite multiple early designs for datatyping]

2b. Reference to an appendix with Jeremy's discussion of some alternative 
designs, noting that this isn't exhaustive but illustrative of the 
technical difficulties we face and also that we did consider 
alternatives.  This is by way of response to the I18N claim that they 
offered alternative solutions.

3.  Note that many of the difficulties we have faced in clarifying the 
earlier M&S design were caused in part by ill-considered late additions to 
that specification, and the consequent implementation practices that have 
grown up as a result [cite examples?]

4. Summary:  in the absence of a compelling claim that anything is actually 
broken (i.e. despite prompting for actual cases where the current solution 
is inadequate, none has been offered) we feel that it is more important to 
deliver what we have than to risk failure to deliver anything at all.   A 
point to draw out here is not to claim that alternative technical designs 
are not possible, or maybe even better than what we have, but to note that 
the effort of producing one may be too much for this WG and it's allotted time.

Appendix:

Jeremy's discussion of some possible solutions, from [2]

References to supporting material
]]

My hope would be that the main response would be no more than a page, or a 
couple of screens of text, and the detailed technical arguments are 
available through references to supporting material.

Does this help?

#g
--

[1] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Sep/0276.html

[2] http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Sep/0275.html

[3] 
http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Sep/att-0275/i18n-part.html



------------
Graham Klyne
GK@NineByNine.org

Received on Tuesday, 30 September 2003 06:05:02 UTC