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

Re: limits of the generic

• To: Jeni Tennison <jeni@j...>
• Subject: Re: limits of the generic
• From: Uche Ogbuji <uche.ogbuji@f...>
• Date: Mon, 30 Sep 2002 16:30:42 -0600
• Cc: Jonathan Robie <jonathan.robie@d...>, xml-dev@l...
• In-reply-to: Message from Jeni Tennison <jeni@j...> of "Mon, 30 Sep 2002 19:18:07 BST." <137357118919.20020930191807@j...>
• Sender: uche.ogbuji@f...

> I'd view the W3C XML Schema Datatype library as being a
> prescriptive/procedural set of data types, because they do explicitly
> specify how they should be processed. You can treat them just as
> labels if you want, of course, and use some generic data type
> processing to manipulate them. That would be like treating XSL-FO as
> just another XML markup language -- displaying a document written in
> XSL-FO as a tree rather than in the layout that the XSL-FO specifies.
> 
> Extending the analogy, it seems to me that XQuery/XPath 2.0 is like an
> XSL-FO processor, in that it's specifically designed to be able to
> operate over a particular set of data types.

Yes.  Which is my problem with WXS, XQuery and co.


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



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


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

• Follow-Ups:
  • Re: limits of the generic
    • From: Jeni Tennison <jeni@j...>

• References:
  • Re: limits of the generic
    • From: Jeni Tennison <jeni@j...>

• Prev by Date: Re: [Ann] Next generation XSL-XHTML tools from ALT Mobi le
• Next by Date: Re: Are hyperlinks presentation or content?
• Previous by thread: Re: limits of the generic
• Next by thread: Re: limits of the generic
• Index(es):
  • Date
  • Thread