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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] keys and idrefs - XSLT2 r, Jeni Tennison | Thread | Re: [xsl] keys and idrefs - XSLT2 r, Henry S. Thompson |
RE: [xsl] Saxon 6.4.4 (out of memor, Michael Kay | Date | Re: [xsl] Saxon custom extensions p, Joerg Pietschmann |
Month |