[
Lists Home |
Date Index |
Thread Index
]
[Elliotte Rusty Harold]
> At 9:31 AM +0100 5/7/02, Michael Kay wrote:
>
> >I don't think it's acceptable, if people go to
> >the trouble of defining the data types they are using in their documents,
> >that XPath and XSLT should ignore this information and treat eveything as
if
> >it were text (or guess that it might be a number, as XPath 1.0 does).
>
> It is all text. The idea that there are any numbers whatsoever in an
> XML document is an illusion that is sometimes useful in a particular
> local processing environment. XSLT should allow particular strings to
> be converted to numbers (including NaN) at the specific request of
> the stylesheet. The stylesheet needs to be in control, not the
> schema. If the stylesheet says it's a number, then it's a number,
> whether the schema agrees or not.
>
> >Anyway, we get messages every week on xsl-list from people asking how to
> >manipulate dates. I would love to reduce the complexity of the solution,
but
> >I don't think we can deny that the requirement exists.
> >
>
> There are no dates in XML documents either. There are strings and
> elements which some local processing environments may choose to treat
> as dates. In fact, I'm already doing this today using EXSLT, without
> any schema anywhere in sight. Schemas are no more necessary to add
> date processing functions to XSLT than they are to add numbers. This
> is a huge red herring.
This is really the "it's a document" vs. "It's data" argument, isn't it? If
I'm creating an XML message to transport data from a database, then I want a
date to be a date and not just a string. If I'm marking up an article,
everything is text.
[Mike Kay]
> The purpose of static checking is to reject as many incorrect
> programs as possible before executing them.
Worthy, and yet the use of scripting languges is widespread. Many people,
for many purposes, find that the cost of using extensive static type
checking is too high for the kind of programming they want to do.
The point is that there is room and need for both. The real question is how
to avoid extra complexity and large, slow programs for those users, like
Simon and apparently Rusty (and, most of the time, me), who don't want to
use typing capabilities.
Does anyone see a way to have a typing mechanism in XPath/XSLT be in an
optional layer? I would think that support for types, especially full PSVI
complex types, would have to be build in at a pretty deep level, but maybe
there is another way. I'm thinking here about a layer whose omission would
make the processor significantly lighter-weight, as opposed to having all
the code in there but you don't have to use it.
Cheers,
Tom P
|
