[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: Mon, 30 Sep 2002 23:52:26 +0100
• Cc: Jonathan Robie <jonathan.robie@d...>, xml-dev@l...
• In-reply-to: <E17w94B-0001LT-00@m...>
• Organization: Jeni Tennison Consulting Ltd
• References: <E17w94B-0001LT-00@m...>
• Reply-to: Jeni Tennison <jeni@j...>

Hi Uche,

>> I'm wondering how far you could get with a processor that took a
>> more generic view of data types. Perhaps one where the way in which
>> operations can be performed over values of particular data types
>> was described in an external specification, a bit like the way you
>> can define how to display an XML document using CSS. It would need
>> to have some basic building-blocks that it knows how to manipulate,
>> such as "number", "string" and "boolean", in the same way that CSS
>> has some basic building-blocks that it knows how to display, such
>> as "block", "inline" and "list-item".
>
> This is what I've been making myself hoarse calling for. As I
> mentioned, I hope to figure out how to propose this sort of thing
> for EXSLT.

I realise that this is what you've been calling for (my previous email
to you [1] outlined the approach I thought you were suggesting) -- I
was just trying to lead Jonathan to the same conclusion :)

I think this would be a great thing to have in EXSLT. I also see it
being useful for RELAX NG data type libraries.

>> I'm thinking of something where a data type library could provide a
>> formal specification of how to perform operations on a type, which
>> the processor would then read and use when performing those
>> operations. For example:
>> 
>> <dt:datatype name="my:UKDate">
>> <!-- a date in the format DD/MM/YYYY -->
>> 
>> <dt:components>
>>   <dt:component name="day" select="substring(., 1, 2)" />
>>   <dt:component name="month" select="substring(., 4, 2)" />
>>   <dt:component name="year" select="substring(., 7, 4)" />
>> </dt:components>
>> 
>> <dt:compare to="d"
>>   select="if (#year > $d#year) then 1
>>           else if (#year = $d#year) then
>>             if (#month > $d#month) then 1
>>             else if (#month = $d#month) then
>>               if (#day > $d#day) then 1
>>               else if (#day = $d#day) then 0
>>               else -1
>>             else -1
>>           else -1" />
>> 
>> ...
>>           
>> </dt:datatype>
>
> Hmm. in my approach, the basic building blocks are simple XSLT and
> XPath 1.0. A set of new extensions is necessary, but no new syntax.

I didn't want to frighten Jonathan off with XSLT syntax for doing the
comparison function. As for the component-referencing, what were you
intending? I guess that a tree structure would be another option,
something like:

<dt:parse>
  <day><xsl:value-of select="substring(., 1, 2)" /></day>
  <month><xsl:value-of select="substring(., 4, 2)" /></month>
  <year><xsl:value-of select="substring(., 7, 4)" /></year>
</dt:parse>

<dt:compare>
  <xsl:param name="d1" />
  <xsl:param name="d2" />
  <xsl:variable name="result">
    <xsl:choose>
      <xsl:when test="$d1/year > $d2/year">1</xsl:when>
      <xsl:when test="$d1/year = $d2/year">
        <xsl:choose>
          <xsl:when test="$d1/month > $d2/month">1</xsl:when>
          <xsl:when test="$d1/month = $d2/month">
            <xsl:choose>
              <xsl:when test="$d1/day > $d2/day">1</xsl:when>
              <xsl:when test="$d1/day = $d2/day">0</xsl:when>
              <xsl:otherwise>-1</xsl:otherwise>
            </xsl:choose>
          </xsl:when>
          <xsl:otherwise>-1</xsl:otherwise>
        </xsl:choose>
      </xsl:when>
      <xsl:otherwise>-1</xsl:otherwise>
    </xsl:choose>
  </xsl:variable>
  <xsl:result select="number($result)" />
</dt:compare>

>> Of course there's always a trade-off to be made between generic
>> processors and specific processors (gosh, I've even managed to make
>> this email relevant to the subject line again!) but if data types
>> are nothing more than labels, are really declarative, then I think
>> that generic processing is a real option. Certainly one that would
>> be interesting to explore.
>
> This trade-off is why I've also been making myself hoarse calling
> for layering. I don't object to someone plugging in one of those
> shiny fancy optimizers Jonathan is always talkign about. I just
> don't want the socket for that optimizer to be so big and intrusive
> that it leaves no room for a simpler layer of generic processing.

I think that maybe from the optimiser's point of view, they don't want
to have to switch context into some XSLT/XQuery function definition
in order to know how to test whether two numbers are equal to each
other. But then again I don't see any problem with processors that
choose to build-in support for the W3C XML Schema data types rather
than relying on external user definitions.

Plus (a) of course these implementations are going to have to look at
some external data type definitions *anyway* -- those defined by the
user in whatever schema they're using and (b) something along these
lines would be a nice way to support custom collations.

By the way, I know that you're hoarse, but shouting in the direction
of public-qt-comments@w... is probably the best way to prompt
changes. Apologies if you've already sent this suggestion there and I
missed it.

Cheers,

Jeni

[1] http://lists.xml.org/archives/xml-dev/200209/msg01148.html

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

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

• Prev by Date: Re: Are hyperlinks presentation or content?
• Next by Date: Re: TreeView XSL
• Previous by thread: Re: limits of the generic
• Next by thread: Re: limits of the generic
• Index(es):
  • Date
  • Thread