XSLT planning
We are planning what features /improvements need to go in the next release for XSLT. We are making these decisions based on customer input and feedback. So I would like to hear your views on what you would like to see in the release of XSLT.
We are evaluating
XSLT 2.0 -
1. Do we need to support XSLT 2.0 ?
2. What are the most useful features of XSLT 2.0 that you would like to see implemented? (like grouping , support for datetime etc)
3. Do you believe support for the entire 2.0 spec is useful? If yes , why?
XSLT over large documents -
1. What are some of the large document sizes that customers apply stylesheets?
2. Has anyone run into memory issues or perf issues while loading large documents ?
3. What were the workarounds you used for memory issues?
If there are other issues around XSLT/XPATH you would like to be specifically addressed in future releases, please let us know.
Looking forward to hear your comments.
Thanks
Nithya
Comments
- Anonymous
June 07, 2005
On XSLT 2.0:
1. yes.
2. grouping, temporary trees, user-defined functions, xpath 2
3. I don't think XML Schema support is useful because I don't use XSD (preferring RELAX NG). Full base support would be fine.
I'm working on some complex citation processing stylesheets I doubt I could do with 1.0. - Anonymous
June 07, 2005
The comment has been removed - Anonymous
June 07, 2005
XSLT 2.0
1. Yes
2. support for sequences, xsl:for-each-group, xsl:next-match...
3. Yes, I dont want the usage to be very far removed from W3C standards. Base with extensions seems (if not a big performance hit). - Anonymous
June 07, 2005
Microsoft XML Team's WebLog : XSLT planning Huh, who knew? ;) Directly from the above linked post:... - Anonymous
June 07, 2005
I wish a extensive XSLT 2.0 support ..
Regards,
Mukul - Anonymous
June 07, 2005
I wish a extensive XSLT 2.0 support ..
Regards,
Mukul - Anonymous
June 07, 2005
What about "Translet" for large documents? I have used earlier version of Translet and found them to be quick efficient for large documents. - Anonymous
June 07, 2005
I don't personally want the xml schema binding, however given Microsoft's interest in XML Schema and its usage in various products I think full support of the spec could be a benefit to you. - Anonymous
June 07, 2005
comments re XSLT 2.0;
- Result Tree Fragments: getting rid of RTF makes it much easier to create pipelines of processing, though I wonder what type of incompatibility this presents with the use of node-set extensions in existing XSLT 1.0. I for one would like to see some of the core EXSLT supported for portability, with exsl:node-set() toping the list
- Datatypes: I see the binding of XML Schema datatypes as a little obtrusive, though after a while they dont seem to get in the way; though there are pitfalls with implicit type casting. I have yet to take advantage of them, as I use the new regexp features to the fullest.
- XSLT is not a programming language:This is reflected in seperating out such functionality into a different spec: I would like to see math, date/time, etc that is defined in Functions spec to be available, though to follow the same 'seperation'.
- Simplifying Complex XSLT: grouping and the ability to define functions makes it much easier to create more reusable and modular XSLT.
- Multiple Output Docs: The defunct XSLT 1.1 defined this and it extremely useful...glad it found its way into XSLT 2.0
- Better String Handling: Regular expression, upper/lower case functions..etc have made XSLT 2.0 a serious text manipulating language
- XPATH Eval: Dynamic evaluation of xpath should have been in XSLT 2.0...I wish this had found its way into the XSLT 2.0 spec..perhaps this support could be given via EXSLT Dynamic module
I could go on, but these are the top level comments.
cheers, Jim Fuller - Anonymous
June 07, 2005
- Yes
2. xsl:for-each-group, xpath 2,
I am currently working on converting Framemaker-generated XML to conform to an in-house DTD, and it would be extremely difficult to do without the xsl:for-each-group element. I am sure that there are other XSLT2 elements that would be useful, but I have gone that in-depth yet.
- Anonymous
June 07, 2005
also wanted to mention
+1 to XSLT 2.0 support!
+1 to EXSLT 1.0 support in XSLT 1.0 as well
gl, Jim - Anonymous
June 07, 2005
I miss some feature from XPATH 2:
- lower-case
- replace
I think it's very important to support XSLT 2.0. Why:
- Instruction are already available; than I have always to look if the feature is working or not
- Other products suppert XSLT 2 (Saxon 7)
The size of documents is growing. We use up to 90 MB for data exchange to different systems.
Thanks
Alain - Anonymous
June 07, 2005
Oh and xsl:namespace and xsl:sequence are handy too. - Anonymous
June 07, 2005
- Yes, please support XSLT 2.0.
2. grouping, regex are things I use the most now
3. Please support the whole spec. (schema is optional for me for now)
I generally work on files of 1 to 10Mb and don't have any issues with size problems. I use Saxon 8.4 and enjoy it.
I do a lot of work as pipelines, keeping different sets of changes separate - I currently use batch files to handle this.
- Anonymous
June 07, 2005
About XSL 2.0: I can hardly believe what I've done so far with XSL 1.0; it's powerful, and, eventually, very intuitive. What I want for XSL 2.0 is very simple: I want it all. Especially regular expressions, grouping, schema awareness, and tunnelling parameters. - Anonymous
June 07, 2005
The comment has been removed - Anonymous
June 08, 2005
In reading some of the posts so far this morning I am LOVING what I am seeing. Excellent feedback and exactly in part with what I am guessing Microsoft is assuming would probably be the case. If I can point... - Anonymous
June 08, 2005
XSLT 2.0 -
1. Do we need to support XSLT 2.0 ?
Given that XSLT 2.0 has a lot more to offer than 1.0, and that compared to XQuery 1.0 is more applicable in the transformation area, it would seem to me logical that there should simply be XSLT 2.0 support, yes. It would make the "programming experience" much more complete.
2. What are the most useful features of XSLT 2.0 that you would like to see implemented? (like grouping , support for datetime etc)
Support for dates yes, also for chained stylesheets, and support to handle big input sources, among other things.
3. Do you believe support for the entire 2.0 spec is useful? If yes , why?
I think yes because then you would serve the whole range of possible use of the language, and avoid many discussions about an incomplete implementation.
XSLT over large documents -
1. What are some of the large document sizes that customers apply stylesheets?
I did some testing there and came to the conclusion that for big repositories a database works best currently. I would also encourage splitting them up. This works also for database tables, actually. I'm talking about hundreds of MB to even Gigabytes here. I for example have one SQL table that contains 3,5 million rows, and measures about 15 GB on disk... I wouldn't even be thinking to represent all that data in a XML document, less to be processing a (search) query over it. In that case, you'd be thinking about creating indexes and catalogs that make querying much faster.
2. Has anyone run into memory issues or perf issues while loading large documents ?
Yes. Large delay times that make the application unmanagable, and the user angry or at least irritated.
3. What were the workarounds you used for memory issues?
Splitting up the source, writing faster XSLT, using different methods of processing, uploading it to a database. - Anonymous
June 08, 2005
I echo others' votes for complete XSLT 2.0 support. It seems that if we XSLT developers want to continue to have Microsoft as an option, full XSLT 2.0 support is a requirement. I have yet to migrate my 100's of XSLT stlesheets to 2.0 simply because we're tied to Micrsoft technologies. If Microsoft does not support 2.0 then I, and others like me, will have to look at other vendors (read Saxon) to supply the needed functionality.
Also, I would vote for focusing effort on server-side rather than client-side transformations. Being able to do client-side transformations would be great, but in this more competetive browser market, I would be much more interested in a solid server product. If client-side development can continue after that, all the better, but I recommend focus on the server-side.
Thank you. - Anonymous
June 08, 2005
The comment has been removed - Anonymous
June 08, 2005
Currently dealing with documents of about 90MB-150MB which contain some header information and 19,000+ items.
My current approach has to been to create a document spliter that works on the raw document breaking out each item with the header information and then doing a separate transform on each item and writing out the result of each transform as I go. This works because each item is self contained (apart from the header information).
I wonder if there is a potential for a library here to do something generically for this kind of file. - Anonymous
June 08, 2005
- extension functions at compile time
- template match index if there are multiple templates with similiar match like elementname[@value='something'] and the only difference is somthing. faster matching.
- Anonymous
June 09, 2005
After long arguments and petitions, Nithya is collecting feedback on what the XML Team should focus on... - Anonymous
June 10, 2005
The comment has been removed - Anonymous
June 11, 2005
On XSLT 2:
1) Yes!
2) Multiple output, grouping, tunneling, string handling, temporary trees, ...
3) XSD support isn't necessary for me. But I want full base support since a half-baken implementation doesn't attract me! - Anonymous
June 13, 2005
- Yes
2. Multiple Output, grouping
3. I think so, like others have already posted Schema support would be nice, but not neccesary
- Anonymous
June 13, 2005
- Yes
2&3. We use StyleVision to create our xslt, so bacisally anything our designers can do with StyleVision we would need
The largest xml file we have processed to date was 156K.
- Anonymous
June 14, 2005
I second all the comments regarding XSLT 2.0 support - it would be nice to have full 2.0 compliance.
Please give us a fully managed XQuery implementation! If MS doesn't give this to us, we will be forced to go to third party implementations. XQuery is a very important part of our future development.
Thanks - Anonymous
June 15, 2005
The comment has been removed - Anonymous
June 16, 2005
The comment has been removed - Anonymous
June 16, 2005
ad XSLT2.0
1. yes, we need
2. default namespace for transformed doc, temporary trees (anyhow operating nodes, node sets at higher abstract level), xsl:next-match
3. hm, I do not know, but maybe it is easier to implement whole spec than cut off some features ;-)
ad complex docs
1. not so large, single doc max. about 250 KB of characters, and after grouping all together cca 3,5 MB of chars
2. XSLT itself has no mem/perf problem for me, but XMLDiffView, when comparing two 250 KB docs, has the problem :-), but this is out of core.
3. see 2. - Anonymous
June 17, 2005
P.S. to my above comment let me add that one of the most useful features of XSLT 2.0 (actually XPath) is the replace() function for strings. - Anonymous
June 18, 2005
- Yes
2. Multiple Document Output, Grouping
3. If the choice is between wait a long time to have the whole spec implemented or sooner but a small subset of the spec I would go with a subset (as long as you include my wishes LOL).
- Anonymous
June 21, 2005
monogatari The best approach to interoperability is to focus on getting widespread, conformant implementation of the XSLT 2.0 specification. Atsushi Eno doesn't blog often but when he does I tend to drop whatever it is I am doing and devour... - Anonymous
July 06, 2005
The comment has been removed