[
Lists Home |
Date Index |
Thread Index
]
Hi Uche,
> This seems to indicate that I didn't understand what you meant in
> your first message. I don't want a new template language for
> defining DT operations. Nor do I want to overload XSLT to this task.
> Why do we need such a language-neutral language, anyway?
Well, if I've understood your question, I'm assuming:
1. that values are stored as type-labelled strings, as described in
the current XPath 2.0 data model [1]
2. we want to provide a way for users to overload the core XPath
operators in order to use them with their own types
(both of which I think you probably disagree with). Under those
assumptions, using XSLT to define the operations declaratively seems
as good a choice as any, for XSLT anyway. You can think of:
<dt:datatype name="my:UKDate">
<dt:compare>
...
</dt:compare>
</dt:datatype>
as being equivalent to:
<func:function name="my:compare-UKDates">
...
</func:function>
Where any function whose local name starts with "compare-" is used to
work out how to do =, !=, > and <.
But I think we ought to discuss the assumptions first in case I'm
being naive to make them.
> All I want is a simple means of mapping lexical values to host
> language stubs, and a means of naming the operations for operating
> on the resulting value spaces. The basic building blocks I mean in
> XPath and XSLT are simply FunctionCall and the related extension
> mechanisms. Maybe one could find a useful way to take advantage of
> the pattern matching infrastructure as well.
The <dt:parse> thing that I suggested (and which Eric rightly pointed
out is very similar to the xvif approach, and of course its conceptual
ancestor, Simon's Regular Fragmentations) was a means of mapping from
the core XPath string to a my:UKDate value; it's a structured value,
and you expressed a dislike for introducing a new concept of
'component' for those values, so I used XML to represent it.
Perhaps it would be better to have explicit code for the separate
casts to and from number, string and boolean, with defaults that say
that if you don't specify how to cast to/from a number then it means
the same as saying "cast to a string, and then to a number", and so
on.
>> By the way, I know that you're hoarse, but shouting in the
>> direction of public-qt-comments@w3.org is probably the best way to
>> prompt changes. Apologies if you've already sent this suggestion
>> there and I missed it.
>
> You're right, of course. I have been hoping to sharpen my thoughts
> and have a strong counter-proposal. If I get around to the EXSLT
> proposal, this would help.
>
> So far, I've just resigned myself to ignoring XPath 2.0, XSLT 2.0
> and XQuery.
Back with the first release I thought "this design is just dreadful,
but they're just the first WDs, and James Clark is in the WG; he'll
make sure it isn't totally screwed up". Then he left. Then on the next
release I thought "this design is just dreadful, but they're just the
second WDs, and Mike Kay is in the WG; he'll make sure it isn't
totally screwed up".
Now we're on the third or fourth WD (depending on the spec), heading
rapidly for Last Call, and I wish I'd raised more of my concerns, more
loudly, earlier in the process. I don't want to see a pair of
languages that I loved for their elegance and simplicity turned into
the monsters that they're becoming. But I'm just one, easily ignored
voice, without a big corporation behind me and without either James
Clark's or Mike Kay's authority. Now I'm an invited expert on the WG I
can argue, I can vote, I can register dissent, but I doubt that any of
that will turn this juggernaut around.
XSLT and XPath users of the world, unite! The WGs will take your
silence as approval, not disgust. Send your comments to
public-qt-comments@w3.org. It doesn't matter if you don't have a
solution to all of XPath's woes -- the WGs are there to create the
solutions -- but it does matter if you think the languages are off
track, especially if that means you're not going to use them. None of
us want XPath/XSLT 2.0 to turn into another W3C XML Schema or XLink.
Cheers,
Jeni
[1] http://www.w3.org/TR/query-datamodel/#AtomicValue
---
Jeni Tennison
http://www.jenitennison.com/
|
