XSLT planning

XSLT planning

Rate This
  • Comments 36
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
  • 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.
  • We have several projects running now that use XQuery 1.0 draft, so I would really like to see that integrated into the platform.

    Our current solution is to generate XML using .NET DOM support, serialize out to a file, and then execute an external command-line XQuery engine. After the process completes, we parse the resulting XML file into DOM nodes. This process is obviously very inefficient.

    Therefore, we would vote for XQuery support built right into .NET, with the ability to consume and produce DOM nodes.
  • 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).
  • Microsoft XML Team's WebLog : XSLT planning Huh, who knew? ;) Directly from the above linked post:...
  • I wish a extensive XSLT 2.0 support ..

    Regards,
    Mukul
  • I wish a extensive XSLT 2.0 support ..

    Regards,
    Mukul
  • What about "Translet" for large documents? I have used earlier version of Translet and found them to be quick efficient for large documents.
  • 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.
  • 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
  • 1. 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.
  • also wanted to mention

    +1 to XSLT 2.0 support!

    +1 to EXSLT 1.0 support in XSLT 1.0 as well


    gl, Jim
  • 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
  • Oh and xsl:namespace and xsl:sequence are handy too.
  • 1. 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.
  • 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.
Page 1 of 3 (36 items) 123