SSDN - transform XML Schema value or lexical space?

XML Editor

Sign Up

Search

Options

Chat

Help

News

Log in

Not Logged in

Topic

Topic Page 1 2 3 4 5 6 7 8 9

Hans-Peter Küchler

Subject: transform XML Schema value or lexical space?
Author: Hans-Peter Küchler
Date: 31 Oct 2001 06:38 AM

Hi,
I'm using XML Schema for defining element types. Should a XSL transformation use the lexical space (as stylus do) or the value space of a XML document for the transformation? Lexical and value space are defined in "XML Schema Part 2: Datatypes". I think it should use the value space for transformation not the lexical space!

Hans-Peter Küchler

(Deleted User)

Subject: Re: transform XML Schema value or lexical space?
Author: (Deleted User)
Date: 31 Oct 2001 10:30 AM

At 06:46 AM 10/31/2001 -0500, you wrote:
>From: "Hans-Peter Küchler"
>
>Hi,
>I'm using XML Schema for defining element types. Should a XSL
>transformation use the lexical space (as stylus do) or the value space of=
>a XML document for the transformation? Lexical and value space are defined=
>in "XML Schema Part 2: Datatypes". I think it should use the value space
>for transformation not the lexical space!

Stylus simply implements the XSLT 1.0 specs, that don't distinguish between=
value and lexical spaces; being based upon XML 1.0, XSLT has a limited
number of supported datatypes (string, boolean, number, node-set).
So, if you need to test if "100" and "100.0" are two entries in the lexical=
space for the same entry in the value space, you can do it by comparing
number("100") with number("100.0"); but if you want to compare/manipulate
user-defined datatypes, you need to write your own extension functions.

Summarizing, what you need is going to be addressed by XSLT 2.0 (see
http://www.w3.org/TR/xslt20req paragraph 2.3), that is currently in the
Working Draft status.

Alberto

Hans-Peter Küchler

Subject: Re: transform XML Schema value or lexical space?
Author: Hans-Peter Küchler
Date: 31 Oct 2001 12:09 PM

Yes, XSLT 2.0 paragraph 2.3 could eventually interpreted this way but there is no explicit distinction between lexical and value space. Only the preface of 2.3 refers to "matching and constructing... based on... typed elements and attributes". The specific MUSTs don't say anything about lexical/value space or canonical lexical representation, they will use the type for ordering, grouping, formatting... And it is not only the named type of an element, also the restrictions (pattern, whiteSpace..) of unnamed types refer to value space.
Hans-Peter Küchler

(Deleted User)

Subject: Re: transform XML Schema value or lexical space?
Author: (Deleted User)
Date: 31 Oct 2001 12:21 PM

At 12:16 PM 10/31/2001 -0500, you wrote:
>From: "Hans-Peter Küchler"
>
>Yes, XSLT 2.0 paragraph 2.3 could eventually interpreted this way but
>there is no explicit distinction between lexical and value space. Only the=
>preface of 2.3 refers to "matching and constructing... based on... typed
>elements and attributes". The specific MUSTs don't say anything about
>lexical/value space or canonical lexical representation, they will use the=
>type for ordering, grouping, formatting... And it is not only the named
>type of an element, also the restrictions (pattern, whiteSpace..) of
>unnamed types refer to value space.

Keep in mind that this document is just the list of the requirements that
the XSLT 2.0 specs will need to address/include; it's not a detailed
description of how things will work. In my opinion, the reference to
matching and sorting datatypes clearly refers to the need for XSLT 2.0 to
work inside the value space; but we will have to wait for the first draft
to have a definite answer.

Alberto

Topic Page 1 2 3 4 5 6 7 8 9

Powered by Stylus Studio, the world's leading XML IDE for XML, XSLT, XQuery, XML Schema, DTD, XPath, WSDL, XHTML, SQL/XML, and XML Mapping!

Go to Conference:

Log In Options Username: Password:

Site Map | Privacy Policy | Terms of Use | Trademarks

Stylus Studio® and DataDirect XQuery ™are from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2016 All Rights Reserved.