Talk:XSL Transformations

From Wikipedia, the free encyclopedia

Contents

[edit] 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.

[edit] 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)

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)
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)
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)
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.

[edit] 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.

[edit] 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)

[edit] 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

[edit] 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)

[edit] 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)

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)

[edit] 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)

[edit] 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)

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)
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)
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)

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)
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)
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)
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)
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)
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)

[edit] todo edit items ;;

  • DONE ;; system elements (simple breakdown)
  • element glyphs

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

[edit] 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)

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)
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)
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)
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)

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)

[edit] 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)

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)
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)

[edit] 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)
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)
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)

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)

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)
Thanks all. Good work, I think, guys. --Nigelj 19:23, 30 November 2006 (UTC)

More one sugestion about it: apply KISS principle

  1. use only one source XML to the examples
  2. 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>

[edit] 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)

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

[edit] 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)

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)
  1. ^ http://www.w3.org/TR/xslt#literal-result-element
  2. ^ http://www.w3.org/TR/2002/REC-xhtml1-20020801/#guidelines
  3. ^ http://www.w3.org/TR/xhtml-media-types/#media-types
  4. ^ http://www.w3.org/TR/xslt-xquery-serialization/#xhtml-output
  5. ^ http://www.w3.org/TR/xslt#literal-result-element
  6. ^ http://www.w3.org/TR/2002/REC-xhtml1-20020801/#guidelines
  7. ^ http://www.w3.org/TR/xhtml-media-types/#media-types
  8. ^ http://www.w3.org/TR/xslt-xquery-serialization/#xhtml-output

[edit] 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)

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)