Re: [xsl] keys and idrefs - XSLT2 request?

Subject: Re: [xsl] keys and idrefs - XSLT2 request?
From: "cutlass" <cutlass@xxxxxxxxxxx>
Date: Tue, 16 Oct 2001 13:30:19 +0100
hello all,

----- Original Message -----
From: "Jeni Tennison" <jeni@xxxxxxxxxxxxxxxx>
To: "David Carlisle" <davidc@xxxxxxxxx>

> The requirements that I've seen in questions and comments here have
> been:
>
>  - support for the built-in simple data types
>    (which we all agree on)

+1 on this, maybe learning from the XForms effort (XForms 4.1 XML Schema
Datatypes ) of defining these data types into their 2 categories of Basic
and Full, might be useful. In addition XSLT should only worry about
datatypes for the time being.

though there may be a problem with returned values from proposed extension
functions in XSLT 2.0.

>  - getting attribute default values
>    (of course)

+!

>  - getting a list of possible enumerated values for attribute values
>    (think how useful that could be when doing grouping)
+1

>  - matching elements by type
>    (however much you want to deny it)
this maybe useful in migration efforts, when source data structure can't be
refactored, but otherwise the use of this will depend on how one uses XSLT,
i for one can see this in use of massaging data over a few steps, what
happens when the elements are in different namespaces though ?

many times on the xsl-list; people will have overcomplicated solutions to a
problem that could fundamentally be solved with a restructuring of their
data... oh well i have to admit i agree with DCarlisle on this one.

XSLT use cases fall into a few categories, depending on your point of
development view;

-XSLT currently used as primary xml data query/sorting mechanism: the hope
is to use XQuery at some point for industrial data manipulation, but my
feeling is that with proper schema design and the basic addressing
capabilities with core XPATH will address 90% of data access situations (
come to think of it a text file with grep may also do this.... ); though i
think there are serious optimisation concerns ( which could be solved with
hardware, wouldnt it be nice to have expat burned in on a chip
somewhere....hehe ) with any of the technologies. The point of convergance
between XQuery and XSLT, made by Chris Bayes is valid, but my view is that
XSLT is viewed as a use case from which XQuery will move on from, rather
then pure convergence or we may see that the efforts at the w3 converge
closer,in any event, the adoption of Schema via XQuery will be dependent on
how fast the technology is with respect to existing solutions; methinks this
will be a much longer time then what is expected.

-XSLT used as an xml transformer and mapper: this is a nobrainer, xml to
xml, xml to presentation, content reuse etc.. blah blah blah and places XSLT
in the middle of the XML world. Its this position that gives XSLT its
bipolar personality within the xml community, and it does confuse the
picture as its tremendously useful, which leads us onto requests for Regexp,
Date, etc functionality

-XSLT used as source code generator: great dynaism is gained through
generation of xml vocabularies or classic prog languages using xslt as a
generator.

any others ? without looking at xml patterns ? and has anyone done an xslt
patterns list yet ?

> Admittedly the requests aren't as frequent as those for grouping or
> dynamic XPath expressions, but they are there.

the building of dynamic XPath expressions is extremely important, its
already proven in regular use that XPATH is the mechanism with which to get
at data, if u are in XSLT or whatever XML technology. In fact after reading
most of the responses about this debate it is quite clear that XPATH is the
common denominator between a lot of the XML technologies, this dependancy
should be kept as clean as possible, and XPATH should not be hijacked by the
requirements of any single, ahem, path.

and the incomplete list is ;
--------------------------
evaluation of Dynamic XPATH expressions
Regular Expressions
Multiple Doc output
Dates
Explicit default namespace matching
Text inclusions
Extension Functions

i think some refinements need to occur with xsl:fallback, xsl:output and not
to mention some syntatic sugar liberally sprinkled generously on all would
also be nice.


cheers, jim fuller






 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread