Re: [DM] BEA_006

Yes, Michael, I am personally willing to do that. Let them shot at me 
but I am
willing to try to make them reason about the long term consequences
of our decisions.

I think that when we design a language that is expected to survive
decades we should try to use a simple formula: compute how much
will it cost (globally) the industry in the next 15 (not 5!) years if 
we do X
vs. how much will it cost if we don't do X, and then choose 
appropriately.

What is your estimate about how many XSLT 1.0 programs are there today
  vs. how many XSLT 2.0 and XQuery 1.0 WILL be there in 10-15 years from
now  (hoping that we will not end up with an unusable language ) ?

We should simply optimize for the most frequent case (according to our 
best
estimate).

Best regards,
Dana


On Feb 17, 2004, at 6:07 AM, Michael Kay wrote:

> Daniela, can I ask you to step into the front line (by which I mean the
> xsl-list) to defend the backwards incompatibilities we have already
> introduced? I can tell you it's not much fun, and sometimes I feel I'm
> the only member of either WG who is prepared to stand there and be shot
> at. Users are complaining bitterly about tiny incompatibilities we have
> introduced, and this is certainly not the time to introduce more. They
> are right to be concerned: they have investments to protect that run to
> hundreds of thousands of lines of code.
>
> The data model document is a freestanding document but it is designed 
> to
> be backwards compatible with the XPath 1.0 data model. It has to be, if
> the language itself is going to be backwards compatible. As far as XSLT
> 2.0 and XPath 2.0 are concerned, we are not in a green-field situation
> and we have to accept these constraints.
>
> Michael Kay
>
>> -----Original Message-----
>> From: Daniela Florescu [mailto:danielaf@bea.com]
>> Sent: 16 February 2004 22:56
>> To: Michael Kay
>> Cc: public-qt-comments@w3.org
>> Subject: Re: [DM] BEA_006
>>
>>
>> Michael,
>>
>> I am not sure I understand the statement below.
>> The XML Data Model is a brand new specification and I see no
>> reason why we cannot design it in the optimal way.
>>
>> The fact that we have a Data Model that is inconsistent with
>> the Infoset will cause so much damage to vendors and
>> customers. Hence, any deviation from the Infoset has to be
>> seriously justified, and this doesn't seem to be a serious
>> justification to me.
>>
>> Best regards,
>> Dana
>>
>>
>>
>>> Historically, I think the main reason XSLT 1.0 did it like
>> this was a
>>> philosophy of avoiding dynamic errors wherever possible. We
>> can argue
>>> about the merits of this philosophy (there are arguments on both
>>> sides) but there is little point, because we can't change these
>>> decisions retrospectively.
>>
>

Received on Tuesday, 17 February 2004 14:43:22 UTC