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

Re: limits of the generic

• To: "Dare Obasanjo" <dareo@m...>
• Subject: Re: limits of the generic
• From: Jeni Tennison <jeni@j...>
• Date: Sun, 29 Sep 2002 12:08:03 +0100
• Cc: "Dare Obasanjo" <kpako@y...>, "Jonathan Robie" <jonathan.robie@d...>, <xml-dev@l...>
• In-reply-to: <8BD7226E07DDFF49AF5EF4030ACE0B7E07A972B5@r...>
• Organization: Jeni Tennison Consulting Ltd
• References: <8BD7226E07DDFF49AF5EF4030ACE0B7E07A972B5@r...>
• Reply-to: Jeni Tennison <jeni@j...>

Hi Dare,

> My apologies, I misread and misunderstood the algorithm in the W3C
> XML Schema Datatypes recommendation. Schema authors having to
> rewrite their schemas to take advantage of XQuery is a concern and
> it would nice to here from any who are using the xs:duration type in
> their schemas and combining years, months, days and hours in the
> same value.

It's not *in the same value*, but I mentioned in another email that
I'm dealing with a markup language that represents values at fixed
intervals between certain date/times. The markup language needs to be
very flexible: the date/times can be expressed as years, months, dates
or dateTimes, and the durations likewise could range from about PT1S
to P10Y.

There's no particular reason (from our application's point of view)
*not* to allow users to query the database, and get responses back,
for durations that aren't yearMonthDurations or dayTimeDurations
except for the fact that we wouldn't be able to manipulate the results
using XPath+XSLT 2.0, which is one of our requirements. We're already
altering our desired design in order to make it validatable by W3C XML
Schema, but that's just about the design of the structure so I don't
care about that too much. The limitation on durations actually limits
the information that users can express, which is more bothersome.

If we accept that limitation and make the interval a union type (of
xf:yearMonthDuration and xf:dayTimeDuration) then it means that the
XPath+XSLT 2.0 that we use will be more complicated than if we could
just use xs:duration. To format the durations, for example, I *think*
that we'd have to do something like:

  <xsl:choose>
    <xsl:when test="@interval instance of xf:yearMonthDuration">
      <xsl:variable name="d" select="@interval"
                    type="xf:yearMonthDuration" />
      ...
    </xsl:when>
    <xsl:otherwise>
      <xsl:variable name="d" select="@interval"
                    type="xf:dayTimeDuration" />
      ...
    </xsl:otherwise>
  </xsl:choose>

because without doing the casting we might get static errors, or
dynamic ones when we try to get the year component from a
dayTimeDuration. I need to dig through the casting rules to see
whether this impression is justified.

Plus a big thing is that there would be no way to automatically sort
the datasets in terms of the interval that they measure, which would
be another thing we'd quite like to be able to do. I guess that I
could write a user-defined function that converts
xf:yearMonthDurations into xf:dayTimeDurations to do that, but really
I had hoped that I wouldn't have to do any date/time or duration
calculations manually in XPath+XSLT 2.0.

So it's a pain all round, really.

Cheers,

Jeni

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

• References:
  • RE: limits of the generic
    • From: "Dare Obasanjo" <dareo@m...>

• Prev by Date: RE: limits of the generic
• 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