[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: limits of the generic

• To: uche.ogbuji@f...
• Subject: Re: limits of the generic
• From: Jeni Tennison <jeni@j...>
• Date: Sun, 29 Sep 2002 05:49:17 +0100
• Cc: xml-dev@l...
• In-reply-to: <E17vQax-0006UA-00@m...>
• Organization: Jeni Tennison Consulting Ltd
• References: <E17vQax-0006UA-00@m...>
• Reply-to: Jeni Tennison <jeni@j...>

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.

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 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()))" />

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:

  - 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.

Core XPath would then specify, in terms of these operations:

  - a casting/construction syntax
  - comparison and sorting operations
  - standard operators
  - a generic syntax for accessing the components of structured data
    types
  - a function-calling syntax

Is this the kind of thing that you had in mind?
  
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?

> 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:

  - 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?

>> >   <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.)

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/

• References:
  • Re: limits of the generic
    • From: Uche Ogbuji <uche.ogbuji@f...>

• Prev by Date: Re: Way OT
• Next by Date: Re: limits of the generic
• Previous by thread: Re: limits of the generic
• Next by thread: Re: limits of the generic
• Index(es):
  • Date
  • Thread