[
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?
I was a bit careless with my example. expanded-name() would probably return a
string, which could be the namespace then the local name separated by a
character illegal in URI (note that the NS 1.1. discussion casts a cloud over
this)
Then the example should really be
expanded-name() = expanded-name(ns:foo)
likewise with exsl:expanded-name()
> > 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.
I'll try to put together a proposal for this as well.
> >> 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.
The need to do 1+1 is so much more prevalent than the need to do 2002-09-28
+ P1Y, that they do not, to me, require the same support in th core of XPath.
As was mentioned in this thread tongue in cheek, many people also have real
life need for color processing (take stylesheets that process SVG, for
inctance). Should XPath support a mechanism for adding a given tint to an RGB
value?
1+1 belongs in the core. 2002-09-28 + P1Y belongs in a separate layer. EXSLT
provides this layer just fine, for now.
As for the fact that all processors don't support EXSLT, that is a red
herring. EXSLT shows the way for XPath to build a standardized solution, if
it likes. And after all, EXSLT is a standard just as XPath is.
> >> 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.
The discussion demonstrates (yet again) that WXS types are very ill conceived.
I do not recognize a requirement to support such an ill-conceived technology
in the core of what used to be a very well-conceived spec.
> >> 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...?
A function call rather than an operator is one way. A declaration is anotehr
(see my xsl:sort example). AN explicit check means something explicitly says
that it is imposing the WXS view on a particular operation, rather than its
all being hidden in the magic "=" operator.
> >> 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.
I mean to experiment with something like this in 4Suite, using XVIF. Maybe,
if I can find a general enough expression of it for EXSLT...
> > 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 ;)
But again, I am not trying to prevent others from working in a schema-aware
way. I just don't want that built into the core of XPath. I think it should
be in a separate layer and conformance level. That way neither side has to
impose their prejudices on the other.
> >> 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.)
But the effort of converting to canonical representation is just as much as
the effort of building in the type coercion.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Apache 2.0 API - http://www-106.ibm.com/developerworks/linux/library/l-apache/
Python&XML column: Tour of Python/XML - http://www.xml.com/pub/a/2002/09/18/py.html
Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/webservices/library/ws-pyth10.html
|
