Talk:XSLT

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Mid	This article has been rated as Mid-importance on the project's importance scale.
	This article is supported by WikiProject Software (assessed as Mid-importance).

Brainiac Ideas For Future of XML/XSL/XSLT

I've wondered if someone would relate XML, XSL, XSLT, etc to Lisp, Perl, Lex/Yacc, Parser/Compiler design, because I think it might enlighten people as to the reason why or why-not a distinction is being made. XML, like Lisp, is a syntax free but its not really a language its a abstract data format. Lisp is a programming language where "<" is replaced with "(" and ">" is replaced with ")". XSL, XSLT, XSL-FO, seem to be functional additions that do what LISP does without the confusing recursion. You could probably embed Perl in something like XML and do well with it what you can with all the other XML transformation languages. Lex is a program that turns lexical analysis meta files into lexers, that extract text in a paricular format into useful and identifable pieces, and when coupled with Yacc, can be used to make an interpretive language or a compiler, or a pre-processor. You could probably write a format in XML that defines the structure of a C program, and use XSL to turn that into compileable C code. But you need something outside of XSL and XML to make the code executeable.. Or you could use something like PHP to turn the XML into an executable language. It makes me wonder where the file format begins and the language abstraction ends.

I've thought about the idea of making XML files with embedded functions that transform the XML into other formats, calling it an Object. Then I could ask the "XML object" to transform itself into any format I need, given that the methods needed to do the transformations are either present in the XML file or referenced.

Then I could make stand alone documents that can self-describe their contents in HTML, PDF, Tex and other formats, just by having the document evaluate all its elements, each element in turn being asked to describe itself in the required format.

The functions that the pieces need to evaluate, could either be defined in the XML files, in other XML files, or by making a call to a remote server with a RPC/SOAP style call.

Then it would be possible to include documents from any application into a website, without requiring a number of XSL transformation "Libraries". You could just plop the document into a website, specify the style the document is to be displayed in, and let the documents internal methods determine how to manage this best.

You could probably even preprocess the output, to make sure it follows your design guidlines (overload methods of transformation). Like imagine calling a remote host to perform a transformation on the XML document, the remote host could leave hooks for un-expanded parts of the document, allowing a local pre-processor to expand the un-expanded bits before displaying the results.

Or is XML, XSL, XSLT, XSL-FO, and the expanding need for other XML functional counterparts more easy to comprehend?

-- User? (68.35.1.172) 16 November 2005

Good ideas for the "unifying concepts project" started with web template article and template disambiguation page. -- Krauss 26 November 2006.

Examples

IMO the example should be just on XML transformation and not on generating XHTML output. This is also what the article talks about. There are more than enough tutorials on generating XHTML on the web, so having a more precise and simple example only on XML would not hurt. --Hullbr3ach 16:54, 23 July 2005 (UTC)[reply]

XSLT has to transform XML into something. The article lists 'XML, HTML, RTF, TeX, delimited files, or any other text-based format' as possible options in the opening paragraph. There's only room for one serious example, and I thought XHTML would be an interesting and informative choice, typical of many practical applications. --Nigelj 18:50, 23 July 2005 (UTC)[reply]

I think my point was to see an example where XSL-FOs come into play. Actually, when reading it now, could it be that FOs are always embedded in XSLT "code"? If so, there should be an additional step in the example, that shows the transformed XML code which then contains the FOs, which will in turn be processed to (X)HTML. Right now, it goes straight from XML to XHTML, leaving out the FO step because it "cheats" by providing embedded CSS. --Hullbr3ach 23:18, 6 August 2005 (UTC)[reply]

There is a lot that could be demonstrated, but for the sake of educating someone about what XSLT is and how it works, I think keeping it fairly simple is best. The intended audience is more likely to grok an XHTML example than an XSL-FO one, since the semantics of XHTML elements are relatively well-known, whereas the semantics of XSL-FO elements are obscure (especially to someone who doesn't know what XSLT is). Also, XSL-FO can be produced by any means that XML can be produced, so it would be wrong to assume that XSL-FO is always embedded in XSLT. I also don't know why you put scare quotes around "code" in "XSLT code". Are you implying that XSLT is too declarative or is not an expressive enough language to be considered code? It's Turing complete, and can be used as the basis of higher-order functions… — mjb 09:15, 7 August 2005 (UTC)[reply]

Please don't take the "" quotes to seriously, it was a bit late at night... They were intended to refer to the declarative form of XSLT, but without appraisal. Regarding the example, maybe this discussion should take place here instead? For now, here is an excerpt from [1]

   14   <page-sequence master-reference="bookpage">
   15   <title>Hello world example</title>
   16   <flow flow-name="bookpage-body">
   17   <block>Hello XSLFO!</block>
   18   </flow>
   19   </page-sequence>

You can see, that the FO statements already have content embedded. How did it get there? If there was a separate FO template (if I may call it that), then there clearly can be an example showing how XSLT merges the content into the FO code. If there is no such thing as a FO template, then the only way to get FO markup into the XML seems to be by putting it in the XSLT code in the first place. Don't mistake this as a rant, I'm just trying to understand it and am willing to help edit WP to make this more clear.

How much example code is needed?

Other programming language articles in Wikipedia in general (had a quick look for e.g. at C++, Python) don't seem to have much more sample code than the traditional "hello world". Articles that do have more code than "hello world" tend to be rather long articles. I believe the XSLT article has too much sample code, especially given the length of the article. It's an encyclopedia article, not a user manual or tutorial. In any case without annotation or elaboration, the samples are not very instructive. An anonymous user at 173.180.56.37 just added the below example which I don't think benefits the article and I've removed it to here.

Example 2 (transforming XML to MS Access) Combine the above and used it as a Transform to import to Microsoft Access. XML as follows

 <?xml version="1.0" encoding="utf-8"?>
  
   <event start="190809" title="General Motors Company founded by Billy Durant using Buick"></event>
   <event start="1904" title="Billy Durant at Buick Motor Company"></event>
   <event start="1909" title="Olds Motor Works buyout by Billy Durant into GM"></event>
   <event start="1909" title="Cadillac bought through 4.75m deal"></event>
   <event start="1910" title="Durant removed from GM"></event>

Example 2a (transforming XML to MS Access)XSL as follows

 <?xml version="1.0" encoding="UTF-8"?>
 <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
 <xsl:template match="/data">
  
    <xsl:apply-templates select="event"/>
  
 </xsl:template>
  <xsl:template match="data/event">
    <event>
       <xsl:if test="@*">
       <xsl:for-each select="@*">
       <xsl:element name="{name()}">
       <xsl:value-of select="." />
       </xsl:element>
       </xsl:for-each>
       </xsl:if>
    </event>
  </xsl:template>
</xsl:stylesheet>

--Cornellier (talk) 13:07, 23 October 2012 (UTC)[reply]

Capitalization

...(actually the transformation part, T stands for transformation) Minor editing by current page author required. One transformation should suffice and the remaining one should probably be in Proper Case. (First word CAPITALIZED). --Phil R 18:15, 3 Feb 2004 (UTC)

Anyone who reads an article on Wikipedia can make changes to it; you are the "current page author." If you see something that needs correction, correct it. — mjb 16:41, 13 Jun 2005 (UTC)

The article has since been edited so that the above is no longer relevant.

Using xml-stylesheet PI in examples

I reverted the use of <?xml-stylesheet type="text/xsl" …> in the example code for a couple of reasons. The association of a stylesheet document with an XML source document is something that is normally accomplished when an application feeds both documents to an XSLT processor. Making the association within the source document via an xml-stylesheet processing instruction (PI) usually only happens when the source document author anticipates that the document is going to be loaded into a web browser that will have no other way of locating a stylesheet. The xml-stylesheet PI is therefore not good to include if you want this to be a minimal example of a typical (server-side) application of XSLT. A more important reason not to use the PI in examples, though, is that "text/xsl" is Microsoft's made-up media type for XSLT, and Mozilla only honors it for compatibility. We should encourage people to use the media type specified in RFC 3023 — application/xslt+xml — which, unfortunately, is not recognized by Microsoft products. — mjb 16:41, 13 Jun 2005 (UTC)

Since it's an encyclopaedic article, should it encourage readers to do anything? The browsers are simply following the processing intructions set out in the documentation[2], which states that type does not have to specified; but if it is, its value only has to match a media type in form only (syntactic conformance).

So you could write text/x-fish as a media type. It wouldn't work, but it would still be valid because the form of the type is correct; and if a browser were not to understand either, text/x-fish and application/xslt+xml would be equivalent.

The fact is that major browsers understand the text/xsl MIME type whereas the the XSLT 2.0 MIME type is not. It is inaccurate to say that only Microsoft products do not understand the XSLT 2.0 MIME type:

The Opera browser understands XSLT 1.0 [3] and the MIME type for XSLT 1.0 is either text/xml or application/xml[4].

Mozilla-based browsers (such as Firefox) do not natively understand XSLT 2.0 either[5]

Webkit-based browsers like Safari, Chrome and Midori use libxslt[6] to process XSLT. Libxslt is based on libxml[7], which parses XPath 1.0 - which is used by XSLT 1.0.

In short

the processing instruction shown in the instruction is valid according to the level of language
the example shows a common practice and use of the article topic

And that's all an encyclopaedic article should do - it shouldn't preach. Corey 06:09, 13 July 2011 (UTC)

Smarty vs Templates vs XSLT

XSLT is language neutral, where as Smarty is not (php). Does smarty really belong here? or is there a templating article we can reference instead? IMO This will avoid some confusion.

I agree, smarty does not belong here. Apples and oranges. XSLT on it's own is confusing enough. --MRoderick

Whitespace handling

I haven't been watching this article closely, but as I originally contributed the transform example, I just want to comment on some recent edits (09:54, 2 Jun 2005 Ruidlopes (Other minor edits on pre tags) and 09:50, 2 Jun 2005 Ruidlopes (Fixed some overflows on pre tags' content)).

In its original form, the example also demonstarted some of the idiosyncracies of XSLT's default handling of whitespace in its production of a document. Since Ruidlopes' modifications, this is no longer the case. But then it's easier to read now and people like things neat, so I'm not about to try to put it all back as it was. --Nigelj 18:52, 24 Jun 2005 (UTC)

New 'Processing details' section

I don't want to be a wet blanket, but I'm not sure about Mjb's new - and it has to be said, rather dry and long - section. I code XSLT professionally every day, and I have to say that each time I tried to read through it, my eyes glazed over after a few paras. When I realised that right down near the bottom we're going to begin to see what xsl:apply-templates does, my will to live started to ebb :-)

This is an encyclopedia article, not a HOWTO for XSLT processor developers. Where are the citations, references and wikilinks in all this? Is it original thoughts and research?

My view is that the bottom half of an encyclopedic article may be better off looking at the new facilities promised in XSLT 2.0, looking into Microsoft's stance regarding 1.0, 2.0 and the alternatives, compared to that of the rest of the world. Maybe we could cite some referenced and respected opinions about the future of the technology, for those considering either learning it or basing major projects around it.

What do others think? Maybe there's room for both approaches? --Nigelj 21:25, 27 August 2005 (UTC)[reply]

Well, I want to try to explain the example, because it's really not obvious how the stylesheet generates the result document from the source; and because without an explanation, programmers unfamiliar with declarative, functional programming make numerous, incorrect assumptions about what the stylesheet is actually "doing." It seems prudent to nip in the bud those kinds of common misunderstandings among the readers, if we can.

I originally wanted to just quickly walk through the steps of processing the actual templates and source document given, but it was immediately apparent that it would make no sense if I didn't explain what the processor was supposed to be doing, in general. Once I finished writing about that, though, I was done for the day and resolved to write something more specific to the example later. I'm sorry the intermediate result was a little dry. :/

Citations and references aren't terribly necessary, are they? They would all come from the same source: the spec. I've co-written an XSLT processor and am very familiar with what goes into processing XSLT. I like explaining it to people, as well, since it helps them author better stylesheets.

Re: XSLT 2.0 and beyond, I would be cautious when talking about (and promoting) XSLT 2.0. We should report with the most detail on what Is, not on what Is Hoped Will Be. XSLT 2.0 is also somewhat contentious; not so much for what it brings to XSLT, but more for all the XSD, PSVI, XQuery baggage dragged along with XPath 2.0; it is my understanding (confided to me by about as high a source as there is) that it is these features, advocated by certain stubborn working group members representing certain stubborn corporations that want to bend XSLT to fit their way of doing things, that have been bogging down the new standards' development all these years. — mjb 19:21, 28 August 2005 (UTC)[reply]

Browser support

The article claims that Opera 9 supports XSLT. But on the opera web site relase 8.5 may be downloaded only. 62.202.122.180 15:17, 22 December 2005 (UTC)[reply]

What's the problem with the XHTML example?

I have been ignoring the comments that had accreted below 'Example 2' in the article, as I honestly didn't know what they were getting at. Now I see that Mjb has re-written the paragraph, 'for accuracy'. He says:

Although this XHTML is valid, it does not adhere to the XHTML 1.0 compatibility guidelines for XHTML served with the text/html Internet media type, so it may not render so well in browsers that are not designed to process XHTML. XSLT 2.0 plans to address this by providing implementation guidelines for an 'xhtml' output

Are "the XHTML 1.0 compatibility guidelines for XHTML served with the text/html" the same ones I know at http://www.w3.org/TR/2002/REC-xhtml1-20020801/#guidelines? What is the problem? The guidelines explicitly use text/html as their example mime type. The W3C's 'XHTML Media Types' document, at http://www.w3.org/TR/xhtml-media-types/#media-types says

The use of 'text/html' for XHTML SHOULD be limited for the purpose of endering on existing HTML user agents, and SHOULD be limited to XHTML1 documents which follow the HTML Compatibility Guidelines. In particular, 'text/html' is NOT suitable for XHTML Family document types that adds elements and attributes from foreign namespaces, such as XHTML+MathML.

Lastly, the only empty element I can see - the meta element that defines the content type - is correctly closed with space/> for backwards compatibility, firstly in the XSLT and then this whitespace was faithfully reproduced in the XHTML. (I was a little peeved at the time when someone once decided to 'improve' the whitespace in the example output, even though it was accurate before, but this was not something that got altered, if I remember correctly)

I know that it is a well-known argument that some believe, even though it often breaks people's old browsers, the mime-type 'application/xhtml+xml' should always be used (maybe to teach them a lesson?). I wrote this example in about 2002 and then developed a whole XHTML/XSLT web site out of this proof of concept. I chose the softest landing I could for my code, and the site has now been live for some years based on what you see here. None-the-less, if someone wanted to change the meta element's mime type, they only have to change its occcurrence in the XSLT, not wait for XSLT2 to help with any fundamental problem.

I must be missing something - what is the problem? Until someone can explain it, I do not accept that we have to wait for XSLT2 before we can do this - I've had it live on the web for years. --Nigelj 16:57, 24 July 2006 (UTC)[reply]

The original author of the final paragraph was concerned that the sample rendering wasn't an ideal example, because when using the output method 'xml', it's almost a given that the processor won't follow the compatibility guidelines (XHTML 1.0 appendix C, yes) with respect to empty elements because the processor has no idea that it is outputting XHTML 1.0, let alone appendix-C-conformant XHTML 1.0. Putting a space in the stylesheet is immaterial; you could put a thousand spaces before the "/>" in the XSLT and it would make zero difference to the output because such lexical cruft is removed by the stylesheet parser long before XSLT processing even begins. The example is actually incorrect when it says the output XHTML would include the space. I think that should be changed.

However, I don't think the sample rendering or the final paragraph that explain its caveats are really necessary at all. They do nothing to enhance the reader's understanding of XSLT. I just wanted to fix the way the paragraph was phrased. My rewrite wasn't that drastic, as you can see by the diff. The only part I really obliterated was the "will not necessarily generate valid XHTML", which was way off the mark; it was evident by the remainder of the paragraph that the author was using the term 'valid' to refer to conformance to the compatibility guidelines, which only apply to XHTML 1.0 being passed to non-XHTML-aware browsers as text/html, so I just tried to rephrase the whole caveat accordingly, with the proper terminology and qualifications. —mjb 01:17, 25 July 2006 (UTC)[reply]

But that's not so. If you look at the original upload I made of this example, before anyone pretty-printed the output, the space is there. That text was copy-and-pasted straight out of Netbeans, maybe v3.4, I can't remember, but it was from their choice of Java XSLT processor at that time (Xalan?). I've just checked the site I developed after this example (live on line). That uses the MSXML4 processor and all the empty-element spaces are there too.

So, although the XSLT spec may be unclear on the matter (the xsl:preserve-space top-level element is not directly relevant), the point is that you get completely valid and backwards compatible XHTML using either of those processors. As the years have gone by and other processors have appeared, so the need for backward compatibility in most common browsers has receded.

So while I agree with the text "Although this XHTML is valid," I do have an issue with the rest of it, viz: "it does not adhere to the XHTML 1.0 compatibility guidelines for XHTML served with the text/html Internet media type, so it may not render so well in browsers that are not designed to process XHTML." Just not so, in my experience, as the example correctly shows. I can't speak for all XSLT processors, past, present and future, of course. --Nigelj 19:28, 26 July 2006 (UTC)[reply]

There is nothing unclear about the XSLT spec; XSLT processing operates on XPath node trees, not unparsed source code, and output expectations are straightforward. Recognizing that the result tree is XHTML 1.0 and adjusting 'xml' serialization to match XHTML 1.0 appendix C guidelines isn't mentioned at all, and if performed, is purely a feature of the processor. Here's the first few lines of output from various processors I just tested, if you need a demonstration. (I substituted "..." in the DOCTYPE to prevent long lines).

Saxon 6.5.3:

<?xml version="1.0" encoding="utf-8"?>

<!DOCTYPE html
  PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" ...>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
      <title>test1</title>

Xalan-J 2.6.0:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" ...>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />
<title>test1</title>

4XSLT 1.0rc1 (current CVS):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" ...>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
    <title>test1</title>

OraXSL from Oracle XDK 9.2.0.4.0:

<?xml version = '1.0'?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" ...>
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
   <head>
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
      <title>test1</title>

libxml + libxslt, via lxml 1.0.2

<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" ...>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <title>test1</title>

As you can see, some add the space, some don't. mjb 19:57, 27 July 2006 (UTC)[reply]

OK. Good point, which I wasn't previously aware of. Thanks for the effort in researching it. I've made a change to the article to try to encapsulate this with the minimum number of words and scope for confusion. --Nigelj 20:55, 27 July 2006 (UTC)[reply]

I still don't like it, because it suggests that the processor has copied the space from the input to the output, whereas what has actually happened is that the processor was unaware of the space in the input (the XML parser abstracted that information away before the XSLT processor saw it); the processor just added a space in the output because it was asked to serialize the result tree as XML and the result tree contained elements in the 'http://www.w3.org/1999/xhtml' namespace. —mjb 01:05, 28 July 2006 (UTC)[reply]

I'm not happy with the existence of this whole paragraph under the example, because it borders too perilously close to 'original research' (WP:NOR). Maybe we should delete the whole thing unless you can find some acceptable documentary evidence to back up all these assertions, rather than surveying the behaviour of available processors ourselves right here. --Nigelj 18:07, 28 July 2006 (UTC)[reply]

I'm not worried about verifiability; I could probably dig up some mailing list posts from the implementers of the processors that add the space to confirm that it's a feature, and under what conditions the space is added. However I think we're in agreement on the paragraph being superfluous; as I said above, neither the rendered XHTML table nor the paragraph explaining its caveats are necessary for the reader's understanding of XSLT. I say we drop them both. —mjb 20:30, 28 July 2006 (UTC)[reply]

How about just dropping the paragraph? Someone took the trouble to screenshot the rendered page, the article is short of illustrations, people are asking for it to be less techy and more accessible, and the XHTML is renderable (and that is what it would look like) in suitable browsers, with or without the space in the source. --Nigelj 10:38, 29 July 2006 (UTC)[reply]

The screenshot serves no purpose; it has nothing to do with XSLT. The reader does not get a better understanding of what XSLT is because of it, and leaving it in has already resulted in people adding text about how it won't always render like that. Your example code, and the diagram at the top of the article, is far more illustrative of what XSLT is about than a screenshot of what one might see if one renders, with some non-XSLT tool, the output of one of the examples. —mjb 23:49, 29 July 2006 (UTC)[reply]

todo edit items ;;

DONE ;; system elements (simple breakdown)
element glyphs

dr.ef.tymac 03:05, 23 November 2006 (UTC)[reply]

processing without external XML file, string or stream

Someone said:

"rv ... entire 'standalone' nonsense; there is ALWAYS a source tree w/a root node even if not derived from parsed XML. Example only demos ignoring the rest of the tree."

This removal was unjustified for the following reasons:

did not specifically identify which part of the addition was "nonsense";
did not specifically identify any mistake in the addition;
did not otherwise justify removal (as opposed to clarification, correction of deficiencies, etc.) on the basis of existing WP policies;
it removed other independent content, unrelated to the presented objections, with no justification at all;
introduced low-yield emotionally-loaded disparaging terminology; and
argued a position that the contributing editor had never even challenged or contradicted to begin with.

on the basis of these facts, I intend to clarify, and re-submit the removed portion, and formally request a direct explanation here before the content is further modified, so that we may reach consensus and avoid mischaracterizing the nature, validity, and relevance of any contributions. Thanks! dr.ef.tymac 06:19, 23 November 2006 (UTC)[reply]

For reference: the actual edit you're complaining about.

I fail to see any "non-relevant emotionally-loaded terminology" introduced here; I only removed and rearranged things. What exactly are you referring to?
If you look carefully you'll see the only things actually removed were the phrases "Moreover, XSLT is natively capable of producing result documents other than well-formed" and "and is capable of producing output without requiring XML as input" in the intro, and the related "Example 3". The diff makes it look more drastic because I moved a misplaced paragraph.
The phrase "Moreover, XSLT is natively capable of producing result documents other than well-formed XML" introduced the term "result documents" prematurely, and was addressing a topic that was more accurately covered 2 paragraphs down. Why that paragraph was shoved down into the middle of the 2 history paras is a mystery; as your contribution indicates, it needed to be addressed sooner, so I moved it up, which would render your "Moreover" redundant if we put it back in. The move also allowed for the addition of scare quotes around "transform", as it's not really a transformation but rather, as explained in the next sentence, the production of a new document based on another one. (And I later made a couple of minor edits to be more clear about the fact that XSLT doesn't directly produce "web pages" or PDF documents, per se, but rather HTML and XSL-FO.)
The claim "XSLT processors are capable of producing a result document without relying on an associated XML document" is misleading. There is always a source tree (consisting of at least a root node) and by definition (in XPath) that tree represents an XML document. The fact that a processor could go beyond the spec and operate on a default, minimal tree without parsing serial XML or being handed a DOM node is not a feature of XSLT or its processors any more than making coffee (and is actually a very rare feature among processors!). Likewise, the fact that a stylesheet can be authored in such a way as to ignore all but the root node (which the processor has no choice but to process) does not constitute a capability of processors, really; it's just an aspect of the language, and not a terribly essential piece of info to put into the intro.
It is not obvious how that last claim leads to the conclusion "This is useful in situations such as transclusion of page fragments" or how the example code demonstrates any such principle. The example is merely a stylesheet that ignores the source tree, other than the root node.

All that said, I suppose it wasn't "nonsense", and I'm actually not opposed to making the general point you wanted to make about a source doc being mostly ignorable, though I wouldn't go so far as saying (without heavy qualification) that the source XML is universally unnecessary. It's also a relatively esoteric subject, not something to emphasize so early on. It's more suited to the Overview section that follows the intro.

There, I would say that a stylesheet can be authored in such a way as to essentially operate without a source document; the stylesheet could acknowledge nothing more than the source tree's root node, and since that node doesn't even reflect the actual content of the source document, the actual source document would have no effect on the result tree and output produced. Then I might add that because of this, a processor might offer the option of not even reading a source document, but a survey of current processors (if you can locate one) indicates that option is not usually available; you have to process something, even if your stylesheet ignores it. This is better than saying that a processor "is capable of producing output without requiring XML as input".

I personally wouldn't go further than that, into the realm of demonstrating and speculating about the possible benefits and uses of such stylesheets; it'll just be confusing, and this isn't a tips'n'tricks or HOWTO guide. —mjb 08:21, 23 November 2006 (UTC)[reply]

You make a lot of new (and some contestable) assertions in your prolix response, as well as arguing some positions I have never even *addressed*. Instead of elaborating on this new stuff, I will simply focus on what I believe to be current consensus (based on your remarks):

1) none of what you deleted from my contribution was in fact "nonsense";
2) none of what you deleted was factually inaccurate;
3) some of what you deleted was subject to interpretation, and/or qualification;
4) some of what you deleted was (in your opinion) either non-obvious or potentially confusing;
5) (your interpretation of) my "general point" is worth noting in the article; and
6) the subject matter of the article is sufficiently complex to warrant care to avoid deviating into abstruse and esoteric territory.

Assuming these are correct, here is my proposal for further mutually-satisfactory development of this article:

adress (6) above by judicious use of progressive editing, as well as footnotes, 'scare quotes' and any other readily available means for clarifying content consistent with the policies and objectives of WP; and
address clarification concerns with discussion, repositioning, commenting-out with requests, rather than summarily rejecting and deleting content.

If this sounds reasonable to you, I will do my best to proceed in this manner, and hope you will reciprocate. Thanks! dr.ef.tymac 09:04, 23 November 2006 (UTC)[reply]

Well, if you want to start throwing the rulebook around, WP:BOLD also applies; 90% of the time, editors don't even know there's a discussion page, or even come back to the article to notice whether their contributions survived. That's a moot point now, since your followup edits indicate that you take a deep interest in this article, but I had no way of knowing you weren't a hit-and-run editor like so many who visit this and other related technical articles, so I have no regrets about making the initial reversion without discussion. Usually, discussion isn't necessary.

Re: new positions about topics you hadn't addressed, "XSLT processors are capable of producing a result document without relying on an associated XML document" was an oversimplification with ambiguous implications. "Factual accuracy" is a red herring; you were painting with too broad a brush. It makes no sense for the article to be filled with statements indicating that an XML document is necessary, and then to have this one contradictory statement pop in, without sufficient qualification about what is actually necessary and to what extent.

As for the proposed course of action, you seem to want to get people to agree to your forthcoming edits on principle alone, rather than putting actual edits forward, either here or in the article, for peer review.

I already stated what I felt would be a good place for your principal contribution, I provided ideas on how to phrase and qualify it, so as to be more precise and accurate, and I suggested avoiding speculation and examples that don't clearly demonstrate your point. I'd Assume Good Faith if you made an attempt in that direction, just as I hope you're assuming my edits are in good faith as well. If I see something clearly amiss, I'll try to be courteous and discuss it here, now that I know you're paying attention, but neither of us needs to run everything by the other in advance, unless an edit war is clearly about to be waged. :) —mjb 10:15, 23 November 2006 (UTC)[reply]

Not interested in an edit war, just attempting to reach consensus. I enumerated 6 points of possible consensus, you have yet to admit direct agreement (or opposition) to any of them. You have, however, introduced more new issues and (contestible) characterizations of my motivations that seem to be beyond the scope of this thread topic. I can address the new stuff elsewhere to avoid making this a big deal. I will just assume the matter is resolved to your satisfaction and hope we can help one another to continue to make WP an oustanding resource we can all enjoy. Thanks for sharing your insights and concerns! dr.ef.tymac 11:09, 23 November 2006 (UTC)[reply]

you seem to want to get people to agree to your forthcoming edits on principle alone

I *will* answer this one: Nope, that's not at all what I want ... simply attempting to establish a baseline for what *you* (and the other stakeholders) want; it enables me to focus better. You've helped quite a bit just from what you've written here. Many thanks! dr.ef.tymac 11:27, 23 November 2006 (UTC)[reply]

Move 'Template rule processing' section to XSLT processor too?

I see that today Krauss moved a whole set of notes and external links to XSLT processor. Maybe the section 'Template rule processing' could be moved over to there too? People who are working on that other article will know best how to weave it in. --Nigelj 23:06, 26 November 2006 (UTC)[reply]

Ok, I agree, it is more "abot the processor" than "about the language": moved. -- Krauss 26 November 2006

I don't mind reorganization too much I guess, but the main reason I put that whole section in there was because someone else had earlier written up a completely bogus explanation of "how XSLT works" that was based purely on observations, incorrect assumptions, and fundamental misunderstandings rooted in the way other web scripting and templating languages are often described or implemented. I'm afraid that if the explanation of the processing model is moved elsewhere, we'll get a repeat of that situation. In fact, we just did, and I fixed it just now. It's a dangerous misconception that the template match patterns determine what nodes get processed. Please avoid trying to simplify the explanation so much that it reinforces that misconception. Thanks —mjb 04:11, 27 November 2006 (UTC)[reply]

Yes... I think a good "compressed text" (from the the "Template rule ..." section on the new article) will be better... but it need good english people (I am en-2, and do only a copy/paste from the first phrase). -- Krauss

Heh, OK. I just adjusted the "compressed text" here again, and then I reorganized things further to reduce redundancy. Here's the full diff although it's probably easier just to go look at the article. Also I noticed that XSLT processor redirects to XML template engine, so I changed a wikilink… maybe should change the title of this thread too :) —mjb 05:56, 27 November 2006 (UTC)[reply]

and I just removed that article and redirected it to here, as it was uncited OR mainly containing a useless mix of stuff about xslt and xquery... if anyone thinks anything in it was correct, citeable and useful, and not covered here, by all means merge it in to this article.

We need examples, are illustrative !

Sugestion to REVERT (back) examples -- Krauss 27 November 2006

I agree with the reasoning given in the edit summary ("Wikipedia is not a how-to guide"), and I know this same battle against excessive code samples has been fought (and won) in articles about other languages. However, a lot of work did go into the examples we had here, and there really should be some illustration of actual code, like a "hello world", at least. —mjb 18:53, 27 November 2006 (UTC)[reply]

I don't think there was much value in the new 'Example 3' - it didn't illustrate any of the main uses of XSLT (see lengthy and slightly testy discussion above). But the other two were, to my mind, essential illustrations to what XSLT was like and what it does. They were in no way a 'how-to' guide, but were essential illustrations of the whole point of the language. XSLT is nothing like most other scripting technologies, and from what we have left I can't see how the interested, enquiring reader is going to get much idea what it looks like or how it may be useful. A small amount of nit-picking cruft had accumulated below 'Example 2', and that could have gone too. As it is, I'm wondering if this deletion was not just a piece of slightly educated-looking, but ill-informed vandalism. By discussing it, rather than simply reverting it on sight, we are going a long way towards assuming good faith, but it'll need a lot better justification than 'Wikipedia is not an how-to' (sic) before I believe it was for the betterment of this article. --Nigelj 20:34, 27 November 2006 (UTC)[reply]

Just a note, the "Example 3" really was intended more as a short "hello-world-type" example, with the "no-xml-needed" as a slight (and somewhat pedantic) twist. It definitely won't hurt the article to remove it, anyone, feel free to do so. As an alternative, how about this? dr.ef.tymac 21:37, 27 November 2006 (UTC)[reply]

I've gone ahead and restored the entire Examples section, as a starting point for trimming it down. —mjb 22:54, 29 November 2006 (UTC)[reply]

I will take out example three since consensus feedback seems to indicate removing it will not hurt the article. dr.ef.tymac 23:46, 29 November 2006 (UTC)[reply]

Thanks all. Good work, I think, guys. --Nigelj 19:23, 30 November 2006 (UTC)[reply]

More one sugestion about it: apply KISS principle

use only one source XML to the examples
remove all redundant pullution for didactic intentions

-- Krauss 30 November 2006

(all tested into IE and Mozilla adding line <?xml-stylesheet type="text/xsl" href="file.xsl" ?> on xml file)

Common source:

<?xml version="1.0" ?>
<persons>
  <person username="JS1">
    <name>John</name>
    <family_name>Smith</family_name>
  </person>
  <person username="MI1">
    <name>Morka</name>
    <family_name>Ismincius</family_name>
  </person>
</persons>

Ex1:

<?xml version="1.0" ?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:output method="xml" indent="yes"/> 

<xsl:template match="/persons/person">
	<record>
	<name username="{@username}">
	   <xsl:value-of select="name" />
	</name>
	</record> 
</xsl:template>

</xsl:stylesheet>

Ex2

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

<xsl:template match="/persons">
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
		<title>test1</title>
	</head>
	<body>
		<h1>Persons</h1>
		<ul><xsl:apply-templates /></ul>
	</body>
	</html>        
</xsl:template>

<xsl:template match="person">
	<li>
		<xsl:value-of select="family_name"/>, 
		<xsl:value-of select="name"/>		
	</li>        
</xsl:template>

</xsl:stylesheet>

I think the KISS examples are maybe too basic in that they don't show anything but the simplest case. But maybe I'm too close to this, having created the original Example 2, which shows a wide range of XSLT techniques. But maybe this was the basis of the 'How-To' jibe? (We don't know because that deletor has never been back to contribute anything). Others need to decide on that, but either way I do suggest that the examples both need the expected result or output to be provided too. --Nigelj 15:00, 2 December 2006 (UTC)[reply]

Let see if we see the same about "don't show anything but the simplest case" (and if we have consensus about goals on "KISS illustration")... if we review the old examples, the templates show only the features:

template match="domains/*"     	     value-of select="@ownedBy"
value-of select="local-name(.) 		template match="host"
value-of select="node()"       		href="{$url}"
value-of select="$url"         		apply-templates select="use"
variable name="url" select="normalize-space(concat('http://', normalize-space(node()), '.', local-name(..)))"

But this is not a XPath article, the features illustration are only about:

apply-templates select="xpath"                 href="{xpath}"
template match="xpath"     		       value-of select="xpath"         		
variable name="url" select="xpath"

Comparing this list with (KISS) Ex1 and Ex2, we need add only

apply-templates select="person"
variable name="x" select="xpath"

I think the variable is not a "relevant addiction" (many template languages have variable declaration feature). We can add the sort feature:

<ul> 
   <xsl:apply-templates select="person">
     <xsl:sort select="family_name" />
   </xsl:apply-templates>
 </ul>

It is ok? -- Krauss 2 December 2006

Doed, but if the problem is the "old notes", please delete the notes, not the changes. -- Krauss 17 December 2006

Ex.2/Notes

Old notes: NEED REVIEW/REDO

Note: In this particular example empty elements, such as the meta element in the head, include a space before the final />, as was specified in the XSLT stylesheet. This behavior is not required by the W3C specification for XSLT 1.0 processors, and so these spaces in Literal Result Elements^[1] in XSLT may or may not be reproduced in the output depending on different XSLT processor implementations. The presence of this space in empty elements was specified in the HTML Compatibility Guidelines of the XHTML 1.0 specification^[2] for serving XHTML 1.0 to non-XHTML-capable browsers with a 'text/html' Internet media type. It is not applicable to later versions of XHTML or XHTML served as 'application/xhtml+xml'^[3]. It is not relevant to the most recent browsers (IE 7, Mozilla Firefox etc). XSLT 2.0 plans to address the problem by providing an 'xhtml' output method.^[4].

Sugestion wikthout english review:

Note: for space on output notation and control of HTML undesirable tags, see behavior required by the W3C specification for XSLT 1.0 processors^[5], Compatibility Guidelines^[6], Content-type 'application/xhtml+xml'^[7], and the XSLT 2.0 plans to address the problem (by providing an 'xhtml' output method) ^[8].

Example 2 doesn't look correct

The title in its XHTML output doesn't seem to match the XSLT, and the screenshot uses a different username. Am I missing something here? Davedx 14:56, 12 May 2007 (UTC)[reply]

Nope, you're absolutely right. I recall someone changing the name with the reasoning, "less weirdness in examples" or something to that effect. They obviously forgot to update the screenshot example. I've corrected the inconsistencies. Jerazol 16:12, 12 May 2007 (UTC)[reply]

This is a tech document, not an encyclopedia entry

To qualify as an encylopedia entry, it should discuss where, and how often, this is actually used. Mathiastck 12:08, 19 July 2007 (UTC)[reply]

Produce a reference to a reliable source that indicates this, and feel free to add the information to the article at any time. dr.ef.tymac 13:15, 19 July 2007 (UTC)[reply]

XSLT Criticisms

I thought it might be good to have a subsection listing any 'gripes' that may make people think twice about using XSLT. Then again, they are probably largely combined with criticisms of XML in general.

To start a list though:

Possible confusion between XSL stylesheets and the more widely known CSS stylesheets, which have a completely different syntax and approach. In particular, CSS rules are mainly used to control presentational aspects of [X]HTML documents, whereas XSL involves entire transformations of a document's elements, and output into any textual format.

Verbosity and computational overhead – whilst gzip compression is widely available to dramatically shrink text files, by their very nature, text files allow for concise-yet-still-humanly-readable data representations and instructional markup. This is a general XML criticism that some people have though, with regards to the proliferation of closing tags that are perceived to be redundant, and the presence of both element attributes and children when one or the other would suffice.

XML is traditionally understood to be a simple markup language, so why attempt to twist it into a Turing complete data manipulation language via XSLT? There are other ways of parsing data, and many tools for doing so that are not as computationally intensive. It is said that tools such as AWK introduce complexities, but what about XSLT's unique syntax and template declarations? There is an argument that the perception of greater readability is always better, but for data-intensitive applications I've read that decreasing verbosity in data description languages is important whilst still maintaining enough readability.

You're adopting the wrong approach. If you want to create a section on criticisms of XSLT, you shouldn't be thinking about your own criticisms of the language, you should be researching the published literature for critiques published by respectable authors, preferably in peer-reviewed articles. (Also, edits to talk pages should be signed!) Mhkay (talk) 20:53, 22 June 2009 (UTC)[reply]

Extending the list: (User vlozak - Jan 7, 2010)

xsl syntax is extremely verbose, and xsl stylesheets can become very difficult to understand as a result. We have developed a significant code base of long xsl scripts for data and open document conversion, and only a small fraction of our IT staff have had the patience to work out how to maintain them.

because of the vagaries of in-browser support xslt 2 in particular seems to be having problems gaining traction. This is disappointing as many of the xslt 2 specific numeric and text functions would greatly simplify xsl scripting.

on the plus side xsl seems to be the most efficient scripting language for robustly and rapidly extracting fragments of knowledge from very complex xml data sets. —Preceding unsigned comment added by Vlozak (talk • contribs) 01:55, 7 January 2010 (UTC)[reply]

But again, anecdotal evidence and personal observation has no place here. I'm only aware of one properly conducted usability study, and that was largely concerned with ease of learning rather than productivity; it also studied only very simple tasks rather than large-scale applications (and the tasks chosen were much more suited to the intended field of application of XQuery rather than XSLT). If you're aware of other research, please do summarise it for the article, with citations. Mhkay (talk) 22:19, 11 July 2010 (UTC)[reply]

Lead section

Hi, I made a change to the lead section that XSLTs can transform an XML document into any other type of text document, XML or not. User Mjb corrected me, writing:

"XSLT transforms XML to XML, then optionally serializes that XML as perhaps non-XML. (Technically, it guides a processor which builds & serializes node trees)"

This is certainly correct. However, even if another XML structure is used as an intermediate representation, it still means that XSLT is also used to transform XML documents to non-XML documents. Therefore, the current initial statement of the article appears incomplete or too narrow:

"XSLT [...] is [...] used for the transformation of XML documents into other XML documents."

Comments?

In general, I think the lead section is too long. IMHO much of the information should be moved to the overview section with more space to explain it in detail. The lead section needs to be concise and only sketch the general concept of the lemma. --EnOreg (talk) 15:06, 9 January 2011 (UTC)[reply]

The lead is basically the same as it was a few years ago, so it's pretty stable and must be working OK for people, but the last sentence in that older version has been expanded to 3 rather lengthy sentences about what XSLT is typically used for. I liked it better when that topic was in one sentence.

Whatever is there needs to be accurate and not misleading/oversimplified (which was my concern), and writing a concise description of what XSLT is and what it's used for seems like it should be simple. But there's an unfortunate discrepancy between what maybe 50% of people actually use XSLT for (producing serialized HTML) and what the XSLT language requires the programmer to understand: that unlike HTML-generating or HTTP response-generating languages like PHP, JSP, etc., an XSLT document is only guiding the creation of a new XML-based data structure (node tree); must be XML, itself; and normally contains an indication which serialization format is desired (an HTML, XHTML, or XML document, normally...although instead of encoded text, the result could instead be exposed as a DOM).

When people don't pick up on these nuances, they have difficulty, so I feel it's important to try to communicate at least the most essential parts in the lead, such as "XSLT produces XML from XML...and then maybe serializes that XML in some other format." How exactly to say that, though? I'm open to ideas. —mjb (talk) 00:18, 10 January 2011 (UTC)[reply]

Hi Mjb, thanks much for your reply. I like the version you linked to much better: The first paragraph avoids the misunderstanding I was concerned about and it represents a concise yet complete introduction. Just the second paragraph has been rightly moved to the Origins section in the meantime.

What do think about replacing the current lead section with that older first paragraph and moving the additional information from the current lead into the article body? Cheers, --EnOreg (talk) 10:15, 10 January 2011 (UTC)[reply]

I agree about simplifying the lead, and keeping it as a summary of what's explained in more detail further down the article. On the separate point, I'm worried that the node tree that a processor produces (which is then serialised into XML, HTML, plain text etc) is little more than an implementation detail in practice. I have used XSLT to produce large amounts of CSV, and I have to say that throughout the project I was unaware (as an XSLT developer, using various XSLT processors) of any intermediate node tree. There may have been one, but to conceptually understand the process of my XSLT templates (a second XML node-tree) operating on the incoming XML (the primary node-tree) and producing the output documents, I had no reason to give any thought to any third node tree. (This is different to the production of XML and XHTML). Surely something that is conceptually so irrelevant, even to an active XSLT developer at the time, is not worth diverting into in any detail in this top-level article, let alone in its lead? It may be relevant in a more detailed coverage of XSLT processor implementation and design or XSLT processor performance optimisation, but this is not one of those articles. --Nigelj (talk) 12:50, 10 January 2011 (UTC)[reply]

I agree that XSLT was designed to be usable without knowing that you're working with a node tree. I wouldn't call it irrelevant, though, because in my experience training people in XSLT, there was always something that people just wouldn't get, like why they couldn't use xsl:text to generate tags, or why the HTML they were generating needed to be written as well-formed XML in the stylesheet, or why certain XPath expressions didn't work they way they thought they should. I had the same problems when I was first learning. I found that once the node tree model is understood, it not only makes sense, but is something I wish I had known from the beginning. I've always found that we all tend to appreciate a high-level, simple introduction to coding, be it XML, XSLT, or whatever— the kind of "just enter these tags in a text editor and run the files through this program" tutorial that gets you up and running—but eventually people get stuck on things that they hope are syntactic nuances but that actually require relearning some fundamental aspects of the language's design. So, it's my hope that some kind of balance can be struck.

Despite what I've said here, I'm not really that invested in the content of the lead. As long as the article covers that material in some regard, I'm more-or-less satisfied. To be honest, I'm really glad other knowledgeable folks here are taking the initiative on improving the article. Thanks! —mjb (talk) 01:40, 11 January 2011 (UTC)[reply]

Mjb, Nigel, following this discussion, I've now restored the first paragraph of the older, shorter lead that Mjb linked to above. In the process, I strived to preserve all information and references. I moved the discussion of XSLT applications from the lead to a new section. Is this ok with you? --EnOreg (talk) 13:58, 21 January 2011 (UTC)[reply]

Infobox

Propose the following changes to the article

have one infobox, not two. I'm pretty sure one is enough.
instead of using the infobox templates file format and W3C Standard, use the infobox template {{Infobox programming language}}. Obviously there's a certain amount of overlap. Yes, it is a W3C standard. But the article starts with 'XSLT is a language...'. I think the language infobox is more appropriate.
remove the screenshot from the infobox. This really doesn't bring anything to the table, and takes up pixel space, adds bandwidth, etc. There are already code samples in the article. Wikipedia guidelines do state that binary images of text should not be used when plain text can be used. What would be appropriate is an XSLT logo, if one existed.

--Cornellier (talk) 16:13, 28 September 2012 (UTC)[reply]

Done, 05 Oct 2012 --Cornellier (talk) 14:14, 24 October 2012 (UTC)[reply]

Structure of this article

Current structure is (skipping intro, refs, my comments in italics)

History
Concept This is a rarely-used section title in computing articles, what does it mean?
Processor implementations
XSLT and streaming
XSLT and XPath
XSLT and XQuery compared
XSLT media types why is this so prominent in the article?
XSLT examples

I propose the article be structured like this:

History and versions
Supporting technologies XPath, DTDs, XQuery, XSL....
How it works processing workflow, inputs and outputs
Language features paradigm, typing, syntax, variables, branching and control; could discuss limitations and criticism mentioned above
XSLT deployments referenced info on real world usage e.g. Symphony CMS used by some big brands, e.g. Blizzard for WoW
Code samples

--Cornellier (talk) 16:28, 7 November 2012 (UTC)[reply]

Going to start working on this as follows

OLD > NEW

History > History
Concept > Design and processing model
(Didn't exist) > Language features typing, syntax, variables, branching and control,
Streaming / XPath / XQuery > Related technologies
Processor implementations (unchanged)
(Didn't exist) > Usage: APIs, implementations, extensibility, XSL FO
XSLT examples > Code samples

--Cornellier (talk) 21:09, 9 November 2013 (UTC)[reply]

PLEASE STOP COMPETITIVELY DELETING OTHER PEOPLES BNF SOFTWARE

please leave my entry alone. do not "competitively" delete it. if there is a list of software using bnf then this, fairly, is an item:

bnf2xml Markup input with XML tags using advanced BNF matching. (could be used with or instead of XSLT)

(cur | prev) 16:46, 24 May 2013‎ 146.169.25.97 (talk)‎ . . (26,317 bytes) (-140)‎ . . (Undid revision 556521332 by 72.209.222.174 (talk)) (undo)

deleted my little entry not just on this topic page but also on wholey different topic / page. not a coincidence. — Preceding unsigned comment added by 72.209.222.174 (talk) 23:58, 28 May 2013 (UTC)[reply]

What does a BNF-based XML parser have to do with XSLT?

I've removed it because you'd put it in the wrong place. I didn't move it because I see no relevance.

I'd have trouble justifying this link even on the XML article. _Why_?? The whole point of XML is that one doesn't have to worry about parsing it! Andy Dingley (talk) 00:05, 29 May 2013 (UTC)[reply]

that's rediculous. there is a need to tag things into xml. who didn't know that? there are many ways. and bnf2xml is great for some situations. there are few options to go straight from a complex search to xml output in a few miliseconds to find anywhere currently. — Preceding unsigned comment added by 72.209.222.174 (talk) 04:04, 1 July 2013 (UTC)[reply]

I deleted it again, without having seen this discussion. I deleted it because (a) the software linked to is not notable (if we included this, there are hundreds of other utilities we would have to include (we don't link to Rex which is similar and much more notable), and (b) it is only of very vague relevance to an article on XSLT. Essentially, in my view the link was added to raise the profile of a piece of software that would otherwise be (fairly or unfairly) neglected: that is, it's advertising. Mhkay (talk) 08:10, 1 July 2013 (UTC)[reply]

History of XSLT

Could please someone, that has time, to check & to write more about development of XSLT through years: first documentation. Thanks! --TudorTulok (talk) 11:37, 11 March 2014 (UTC)[reply]

version, years, months and the description box includes no years. --TudorTulok (talk) 11:38, 11 March 2014 (UTC)[reply]

Confusing sentence

I’d like someone who understands this better than I do to rephrase this sentence:

This makes a given XSLT program more resilient to change to the input it is likely to receive, useful in a language used for information processing applications.

It might make logical sense, but the language is unclear.

Actually, that whole paragraph is bad. The run on sentence at the end of that paragraph is really hard to follow. Thanks! —giso6150 (talk) 00:39, 6 April 2014 (UTC)[reply]

Venn diagram

Someone added a venn diagram showing supposed relationships between various languages such as XSLT, XPath, XQuery, XLInk and XPointer, and I deleted it.

I know some people find diagrams intuitively appealing, or even worth their weight as decorative ornaments, but I feel they have to say something meaningful, and it was not at all clear what this diagram meant. Putting XPath as the intersection between XSLT and XQuery perhaps makes sense, in that both have XPath as a sublanguage, though it's an informal kind of model because while every XPath expression is an XQuery expression, it's not true that every XPath expression is an XSLT stylesheet.

But the inclusion of XLink made no sense at all. They're in a completely different space. You could as well add SVG or MusicXML to the diagram. Furthermore, XLInk and XPointer are for all practical purposes dead.

Can XSLT-FO Ouptut Produce PNG?

According to the first sentence in this article, XSLT-FO can be converted to PDF, Postscript and PNG. The fist two I agree with. But is PNG really correct?

XSLT (Extensible Stylesheet Language Transformations) is a language for transforming XML documents into other XML documents,[1] or other formats such as HTML for web pages, plain text or XSL Formatting Objects, which may subsequently be converted to other formats, such as PDF, PostScript and PNG.[2]

XSLT-FO has no "output" as such, you would need to use a processor program such as Apache FOP to convert it into something else to make it viewable. As it is, FO is a static document in human-readable, but not particularly intelligible, XML elements. FOP does PNGs just as easily as PDFs.

It is commonly intended to generate PDFs, but PostScript is pretty popular if it's going direct to print and PNG is used quite widely as a rapid online preview just to see if your FO production process is working. Other important uses for PNGs from FO are as either web images (because you want to make a simple web image dynamically and FO is just a simple way of doing it) or where a complex infographic needs to be produced and the production of it benefits from a sophisticated process like FO. These are all cases where direct conversion FO->PNG is a significant function, even though it remains less well known than the "FO is how you make PDFs" viewpoint.

As a trivial other example, if FO can be rendered to PostScript or PDF, these can then be rendered as PNGs by other tools. Although I wouldn't see this as an encyclopedic role for "FO->PDF", as claimed here.

Equally, FO could make JPGs or GIFs (it's all just bitmaps), but I've always found PNGs adequate and a slightly better format for this. Andy Dingley (talk) 10:26, 22 August 2016 (UTC)[reply]

XML Trees

XML Trees are a standard for expressing the hierarchical structure graphically. I recently added an XML tree for XSLT and it fairly immediately got deleted. I know there has been discussion as to whether graphics are necessary or useful within wikipedia (or encyclopedia in general). My students tend to understand and learn better when they have access to the tree structure of these complex structures.

Is it better to not include them at all for the general knowledge reader or have them in a more graphical format? I am partial to ASCII as it is reproducible in code comments but understand it is not as comprehensible to the "I know nothing about the topic" reader.Doryllis —Preceding undated comment added 13:24, 7 December 2017 (UTC)[reply]

Oppose There are several problems with this. Firstly, and most obviously, it's just meaningless. There is no explanation to it, so it's just a dump of some syntax. It does not convey anything useful to the assumed readership of an entry-level article in a general encyclopedia.

Secondly, and most importantly, the syntax of XSLT is not important here (again for the encyclopedic scope). We have to explain the purpose of XSLT, its function, its mode of use and give some examples of its source code and its input and outputs. The syntactical structure of is source is not part of this.

Thirdly it's seriously unbalanced. Explaining the structure of the source code for a typical XSLT transform would focus on the important elements of its syntax: <xsl:template match="..." ... />, <xsl:apply-templates ... /> & <xsl:value-of select="..." /> and issues like push- vs. pull- models. This syntax tree just places all elements, even the relatively unimportant like <xsl:output ... /> at the same level. That's no part of an encyclopedic article at anything like this scope. It would barely pass WP:UNDUE for a dozen page coding tutorial, and that's not what WP does. Andy Dingley (talk) 14:52, 7 December 2017 (UTC)[reply]

Implementations

An anonymous user has been deleting some implementations as "not notable". This is always going to be difficult territory: how do we decide which implementations to include and which to exclude?

There are two products that remain listed (QuiXSLT and XMLStarlet) that I would happily leave out: the first is an incomplete research project, not truly an implementation; and the second is not an XSLT implementation but a user interface layer above an XSLT engine). Meanwhile I can't think of any reason to exclude Altova RaptorXML (I have no great affection for the product because it competes with my own, but it has a significant user base and is a very complete and up-to-date implementation). Another product that has been removed is Exselt; that deletion is more defensible because the product is new and has yet to prove itself; but it has some claim to notability because of its innovative approach even without having yet achieved any market share.

Another notable omission (perhaps because it lacks a convenient name) is the native Microsoft processor in .NET, System.Xml.Xsl.

One danger I think is to treat things as more "notable" because they are more visible in the open source world. It's understandable that Datapower and the Websphere processor are not included, for example, because they are expensive proprietary IBM products with a relatively small user base and little visibility in public discussion. But they are commercially significant for IBM and its customers. I suspect the reason Altova was removed was that the deleter doesn't see it mentioned very often; but that says more about how Altova choose to promote it than it says about the significance of the product.

Another thing I have difficulty with is whether we are trying to write primarily about the situation today or whether the past deserves equal coverage. There have been a number of significant XSLT processors that are now history: xt, Sablotron, 4xslt, LotusXSL, jd.xslt come to mind. I would certainly include xt for its historical significance.

Arbitrary deletions and additions without discussion and reaching consensus doesn't seem a good way of moving forward on this.

Mhkay (talk) 20:44, 4 September 2018 (UTC)[reply]

OK, I've tried to improve the list to cover what might be considered the "mainstream" implementations with a significant user base in 2018.

I've omitted dead products like Saxon-CE and Frameless.IO; research implementations, and user-interface layers that wrap a third-party XSLT engine.
I've added (or reinstated) AltovaXML and IBM Datapower as these are significant and active commercial products.
I didn't include XmlPrime or Exselt or the MarkLogic processor as I suspect they have a fairly small user base, but I wouldn't object to their inclusion as they are real products in real use.
I haven't included historic implementations like xt even though they are historically significant and may still be in active use somewhere.

If you want to add or remove from the list, it would be nice to state your reasons. Mhkay (talk) 08:30, 6 September 2018 (UTC)[reply]

[1] ttp://www.w3.org/TR/xslt#literal-result-element

[2] ttp://www.w3.org/TR/2002/REC-xhtml1-20020801/#guidelines

[3] ttp://www.w3.org/TR/xhtml-media-types/#media-types

[4] ttp://www.w3.org/TR/xslt-xquery-serialization/#xhtml-output

[5] ttp://www.w3.org/TR/xslt#literal-result-element

[6] ttp://www.w3.org/TR/2002/REC-xhtml1-20020801/#guidelines

[7] ttp://www.w3.org/TR/xhtml-media-types/#media-types

[8] ttp://www.w3.org/TR/xslt-xquery-serialization/#xhtml-output

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]