[
Lists Home |
Date Index |
Thread Index
]
> Hi Uche,
>
> > 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()
>
> I suggest using "{namespace-name}local-part" as the syntax since it
> seems a fairly common method of representing expanded names.
True.
> The big problem (aside from the NS 1.1 stuff) is allowing a string as
> an argument. If you had a string, presumably the function would use
> the in-scope namespaces within the stylesheet at the point of the
> function call in order to resolve the prefix, such that:
>
> expanded-name() = expanded-name(ns:foo)
>
> gave the same result as:
>
> expanded-name() = expanded-name('ns:foo')
>
> Trouble arises if the string has been created using the namespaces
> that are in-scope in the *source* document. For example, if someone
> did:
>
> expanded-name() = expanded-name(name(ns:foo))
>
> it probably wouldn't give the right answer (if, in the instance,
> <ns:foo> had a different prefix, or no prefix).
>
> I suggest either only accepting nodes as arguments (which might be a
> good idea anyway, since it's usually if an XPath function accepts a
> node-set and a string, the nodes are converted to their string values,
> so converting to the name of the node might be a bit confusing) or
> having a second argument that provides a context node used to resolve
> prefixes, so you could do:
>
> expanded-name() = expanded-name(name(ns:foo), ns:foo)
>
> to get the right answer.
The problem with accepting only nodes is that you might not have a node handy
whose name matches the value you're checking.
I'd think that if you wanted to use a node from the source document, that you
could simply do so directly. i.e.
expanded-name() = expanded-name(ns:foo))
rather than converting it to string using name(). I agree that accepting a
string *or* a node, and triggering different behavior accordingly is a bit
unconventional, but not so much so that I don't prefer this to the other
options.
But I could also go with a compromise: use two different functions:
expanded-name(node)
expand-qname(string[, ns-context-node])
Actually, I like this best, now.
> > 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.
>
> I agree that a line has to be drawn somewhere. I guess it's just
> selfishness on my part because *I* have to deal with calculations that
> involve adding durations to dateTimes (I'm dealing with some data at
> the moment that are readings taken at fixed intervals starting from a
> particular date/time) so of course I want it to be easy for me to do
> e.g.:
>
> <xsl:value-of select="$dateTime + (position() * $duration)" />
>
> rather than having to use function calls:
>
> <xsl:value-of
> select="add-duration-to-dateTime(
> $dateTime,
> multiply-duration($duration, position()))" />
I think that the added verbosity of the function call is a fine price to pay
compared to the prospect of overloading "+" to death. I will say that even in
OO languages, I've always looked on operator overloading with much caution.
Symbols, carefully chosen, can be a powerful tool for expressivity, and they
can also become a powerful tool for confusioon. C++ iostreams is my favorite
example. IMO, they were an abomination. I and many others I know preferred
to stick to printf even though it provided a bit less formatting support.
(But, of course, not scanf ;-) ). Even better was to provide a polymorphic
pprint() method on relevant opjects that provided formatting constructs *that
made sense for that particular object*.
> or as it would actually be given that I have to use a union of
> yearMonthDuration and dayTimeDuration and we're not allowed to
> overload functions:
>
> <xsl:value-of select="
> if ($duration instance of xs:yearMonthDuration)
> then add-yearMonthDuration-to-dateTime(
> $dateTime,
> multiply-yearMonthDuration($duration, position()))
> else add-dayTimeDuration-to-dateTime(
> $dateTime,
> multiply-dayTimeDuration($duration, position()))
> " />
>
> > 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.
>
> Hmm... So what you'd like to see is a solution that supports data type
> libraries, such that the support for W3C XML Schema data types are a
> module on top of more generic functionality. Core XPath would support
> the basic XPath 1.0 types of string, number and boolean; a data type
> module would specify:
I just want to stop for a moment and say: look at the choice of data types in
XPath 1.0. Now look at how successful XPath has been. I think this gives the
King-Kong-sized lie to the idea that people need titanic data type libraries
to be productive.
> - how its data types could be converted to each other and to the
> core XPath data types
>
> - how values of each data type could be compared with other values
> of that type
>
> - how values of different data types could be added, subtracted,
> multiplied and divided by each other
>
> - for structured data types with several components (such as
> expanded names, dates and times, durations and colours), names for
> each of those components
>
> - any data-type-specific functions
>
> In other words, there would be a fixed "API" for the data type module
> and a module would just have to fill in the gaps.
Pretty much.
> Core XPath would then specify, in terms of these operations:
>
> - a casting/construction syntax
> - comparison and sorting operations
> - standard operators
All the above using the modular facilities XPath provides, i.e. function calls.
> - a generic syntax for accessing the components of structured data
> types
No. Functions can take care of this as well.
> - a function-calling syntax
?? Already there.
> Is this the kind of thing that you had in mind?
In general conception, yes.
> In fact, XPath 2.0 is remarkably and frustratingly close to this state
> of affairs, the main gap being a lack a syntax for accessing the
> components of structured data types -- this is currently done through
> separate (tediously named) functions. Am I on track here?
There is too much intrusion of the separate data type processing into the core
XPath operators, which is the crux of my objection. So XPath 2.0 is actually
way off.
> > 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.
>
> I rather like a magical '=' operator, because it's so easy to use. If
> we had something like that described above, couldn't we say that:
Easy only after you master all the magic. I find such magic dubious. I
prefer things to be explicit.
I also don't like the fact that for some folks, RGB values will always be far
more ueful than dates. And yet they can use = for one, and must use an
entirely different syntax for another.
As you say, one has to draw the line in the sand. XPath 1.0 comes pretty
close to the right position for the line, IMO. I, like you, have had to do
date processing. However, I have never once wished for it to be baked into
the core XPath evaluation engine. Dates are, as I said, orders of magnitude
less important than numbers/strings/booleans.
> - the core XPath data types are compared as in XPath 1.0
> - two data types from the same data type library are converted and
> compared as defined by that library
> - two data types from different data types libraries are both
> converted to strings and compared as in XPath 1.0
>
> and get the best of both worlds?
In what sense is this "the best of both worlds"? Honest question. I think
I've been insistent in articulating that mixing in the complexity of WXS data
types actually destroys the best of the XPath 1.0 world, which is its
simplicity and transparency. And the WXS data type world has precious little
for me that I would likely find useful, so I don't see the gain.
And yes, I have used XML technologies with databases and with strongly-typed
languages. In my experience, if design is properly undertaken, and the layers
of data processing properly separated, the need for specialized data typing
magic is really *much* smaller than its proponents claim.
> >> > <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...
>
> I wonder whether, rather than complexifying the data-type attribute,
> the calculation could be made through an attribute value template. So
> something like (using XPath 2.0 stuff):
>
> <xsl:sort select="@num"
> data-type="{if (@num instance of xs:anySimpleType)
> then 'number'
> else type(@num)}" />
>
> (Except that won't work because there's no way in XPath 2.0 to get the
> type of a node as a string.)
How is it that you think what you have above is putting more complexity into
the data-type attribute than what I proposed? I'll tweak what I proposed a
bit:
<xsl:sort select="@num"
data-type="{schema-derived-type(@num) or 'number'}" />
This seems a lot simpler than what you're proposing. And no new syntax (such
as instanceof) required.
BTW, instanceof is a truly bad idea in a system that has strong ties to OO.
OO is designed to avoid repeated type and capability queries, both of which
are accepted as being notorious causes of maintenance problems in OO systems.
C++ should never have introduced RTTI (they should have started instead by
fixing co-occurence). I think isinstance is just as ill-conceived in
XQuery/XPath.
isinstance would be less of an anomaly in the model if XQuery/XPath 2.0 were
more dynamic and extensible.
--
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/w
ebservices/library/ws-pyth10.html
|
