[
Lists Home |
Date Index |
Thread Index
]
Uche,
>> Examples that spring to mind are:
>>
>> 1. How to compare whether two elements have the same name. In XPath
>> 1.0 you have to compare the local-name() and namespace-uri() to get
>> a namespace-aware comparison. In XPath 2.0, because the names are
>> QNames, you can just compare the QNames.
>
> This has nothing to do with data typing, IMO. The idea of expanded
> name equivalence predates WXS, and is already omnipresent in XPath
> 1.0 (i.e. name tests in the form of qnames). The fact tthat this
> cannot be done in EqualityExpressions is an oversight that can be
> corrected without dragging in all of WXS data types. Just add a
> function expanded-name() (abbreviate it, perhaps), that takes an
> optional QName or a node set. If it's given a QName, that's what it
> expands. If it's given a node set, it uses the expanded ame of the
> first docorder item of that node set. If used without an argument,
> "." is assumed. Then you can simply do:
>
> expanded-name() = ns:foo
>
> in your expressions, and the problem is solved. no?
Sorry, I don't follow. What does the expanded-name() function return?
A node set of two text nodes (or a sequence of two strings in XPath
2.0 parlance)? Or an element that's structured in a certain way?
> Actually, I'd say such an exsl:expanded-name() would be a handy
> addition to the EXSLT core module.
Great. I'm all for adding things to EXSLT if they'll help XPath 1.0
users get the good functionality from XPath 2.0 without the bad
overhead.
>> 2. How to compare whether two date-times are the same when they use
>> different timezones. In XPath 1.0 this would involve some serious
>> work -- you'd have to bug out to XSLT for it. In XPath 2.0, because
>> dateTimes have their own data type, you can just compare them.
>
> EXSLT date-times module provides for this without needing to infect
> the core.
Yes, but as you know there are implementations that don't support the
EXSLT date-times module. Also, I think that users will find it
difficult to understand why they can do 1 + 1 but can't do 2002-09-28
+ P1Y. Native support for date-time values and durations is one of the
main things that's missing from XPath 1.0, in my opinion. Extensions
can plug the gap temporarily, but if we want all users to benefit it
has to be in the core.
>> 3. Similarly, how to compare whether two durations are the same.
>
> I think the subsequent discussion of this one closes the case ;-)
Well, I don't agree. Just because a solution to something is
contentious or hard to define doesn't mean that it isn't a
requirement.
>> You can derive from these examples that I consider the data typing
>> to be most useful for structured data types rather than for those
>> that could be compared as strings if the canonical lexical
>> representation were used.
>
> And I see all the cases you mention better handled by explicit
> checks rather than built-in coercion rules.
Sorry, I don't follow (it must be late). What do you mean by an
explicit check? Something done with a function call rather than an
operator? Or...?
>> Also, I do think that someone who's gone to the trouble of creating
>> a W3C XML Schema schema for their markup language is going to
>> expect that the data types they specified within their schema for
>> the elements/attributes will be used in the document, so that they
>> won't have to do:
>>
>> <xsl:for-each select="item">
>> <xsl:sort select="@num" data-type="number" />
>> ^^^^^^^^^^^^^^^^^^
>> ...
>> </xsl:for-each>
>
> But there is a middle ground. Just one possible way to spell it:
>
> <xsl:for-each select="item">
> <xsl:sort select="@num" data-type="schema-derived()" />
> ...
> </xsl:for-each>
>
> Which has the nice advantage that the user can also do:
>
> <xsl:for-each select="item">
> <xsl:sort select="@num" data-type="schema-derived() or 'number'" />
> ...
> </xsl:for-each>
>
> Menaing "use the schema-derived type if available, and fall back to
> number if it isn't".
I agree something like that would be a very good middle way.
> Can't you see how blindly relying on the schema type makes an ugly
> dependency between the XSLT and the instance document? By handling
> it declarative, as I suggest, the above example is *much* safer for
> modularization and reuse. This is the advantage of generic
> approaches.
Oh, absolutely I can see that. I don't think that it's good practice
to rely on a schema to provide you with typing information about an
instance, any more than it's good practice to rely on a DTD to provide
you with default attributes. But that does not mean that other users
won't want to work in a schema-aware way. In the same way as I don't
think that those users should inflict their prejudices and preferences
on us (and I'm aggrieved that they are), I don't think we should
inflict our prejudices and preferences on them (despite the fact that
we're obviously right ;)
>> if they've already specified that the 'num' attribute is an integer
>> within the schema. This seems the most persuasive argument for
>> including support for W3C XML Schema data types in XPath 2.0.
>
> Doesn't persuade me one bit.
Doesn't surprise me one bit :)
>> But it would be great if we could reduce the complexity of the
>> data-type support in XPath 2.0 as well. Do you have any suggestions
>> about which parts are the most difficult to implement and how they
>> might be made simpler?
>
> This seems obvious to me. The fact that I have to support all the
> comparison rules for all the WXS data types in order to implement
> EqualityExpr is more than enough to bloat the Python function 10x.
> They can be simpler by not being there at all. Why do I have to
> support one committee's arbitrary motley of data types that may have
> nothing to do with any conceivable needs of my users?
>
> At least using generic approaches, I can plug in the details in a
> modular fashion, as they are called for.
I wondered whether it might be the casting that was the problem, since
that seems one of the more complex areas to me.
In terms of dealing with testing equality between the extra data
types, perhaps you can simplify the code by creating the canonical
lexical representation for each value and comparing them as strings?
(I know that doesn't work for some data types where the canonical
lexical representation isn't yet defined.)
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
