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

Re: limits of the generic

Re:  limits of the generic
Hi Uche,

> This is true. I guess if you put it in that light, I can consider it
> with a more friendly eye. I know that XVIF has been designed from
> the beginning to support generic lexical processing. I guess that's
> been what Jeni has been trying to do as well, but it looked as if
> her example was couched in the sense of defining a set of operations
> and lexical mappings tailored to WXS types. Perhaps I was too hasty
> in that judgment.

Right, sorry I wasn't clearer. I wasn't aiming for W3C XML Schema
types -- I was writing to string, number and boolean -- the core types
for XPath 1.0.

> So, starting afresh on this idea, and expressing it in XVIF, which
> has the advantage of a handy implementation right now,

Well, I thought that XSLT had a few handy implementations around, and
the advantage that I know the language, so I thought I'd use that. I
think that ideally these data type definitions could be written in
*any* language, and it would be up to the processor to support
whichever language they wanted.

> People can also put whatever they want into the
> dt:lexical-proprocess element including a pipe that defines some
> other transforms and perhaps a validation step.

Right. I assumed (I'm sorry, I should have written up what I was doing
a lot better) that there would a separate definition that took a
parsed X and validated it. I'm not sure why I thought that separating
parsing and validation would be a good idea; certainly I agree that
once parsed, a value should be validated.

> So now we have the lexical representation mapped to a set of
> sub-elements that can be very readily manipulated by XPath for
> value-space declarations.


> What we'd need to add is some mechanism for such declarations,
> mapping them to operators.


> Maybe:
> <dt:components xmlns="http://relaxng.org/ns/structure/1.0" 
> xmlns:if="http://namespaces.xmlschemata.org/xvif/iframe" 
> dtl="http://www.w3.org/2001/XMLSchema-datatypes">
>  <dt:lexical-preprocess>
>    <if:transform type="http://simonstl.com/ns/fragments/">
>     <if:apply>
>      <fragmentRules xmlns="http://simonstl.com/ns/fragments/">
>       <fragmentRule pattern="^[ \t\n]*([0-9]{4})-([0-9]{2})-([0-9]{2})[ 
>        <applyTo>
>         <element localName="date"/>
>        </applyTo>
>        <produce>
>         <element localName="year"/>
>         <element localName="month"/>
>         <element localName="day"/>
>        </produce>
>       </fragmentRule>
>      </fragmentRules>
>     </if:apply>
>    </if:transform> 
>  </dt:lexical-preprocess>
>  <dt:operator symbol="=">
>    <dt:result>
>      <if:transform type="http://www.w3.org/TR/xpath"
>        apply="$lhs/year = $rhs/year and $lhs/month = $rhs/month and $lhs/day = 
>    </dt:result>
>  </dt:operator>
>  <!-- silly function example -->
>  <dt:function name="dtl:date-in-us-format">
>    <dt:result>
>      <if:transform type="http://www.w3.org/TR/xpath"
>        apply="concat(month,'/',day,'/',year)"/>
>    </dt:result>
>  </dt:function>
> </dt:components>

Absolutely! That's exactly what I was trying to get at.

> Very intriguing idea, I guess, after all. Naturally, optimized
> implementations would not have to use all the above binding info and
> can just jump straight to the optimized code, similar to functions
> that implement EXSLT extensions natively and do not then have to run
> the exsl:function version, though they can always fall back to that
> for classes they do not support.

Yep, absolutely.

> This does only answer one of my complaint: generic dispatch and
> constraint processing. That is a big bone of contention, so I'd be
> happy for such a solution, but the fact is that it still introduces
> a lot of complexity, which is worrisome.

In terms of the operations, I think that a lot of the complexity (from
the user side) can be managed by having sensible defaults. For
example, if a data type doesn't offer a specific equals definition,
then the application could turn it into a string and compare it as a

> However, if it is inevitable that the data types juggernaut must
> have its stone of flesh in the end, I would rather a mechanism such
> as the above allowed others to put their own data types on an even
> keel, and also allowed other forms of axiomatic processing besides
> data types. I also like that it expresses value space operations as
> simple transforms on the plain lexical information, which is an
> important assertion of layering.

OK. Can you describe more about what you mean by that?



Jeni Tennison


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.