RE: Venting

<snip>
The XSL WG is producing a spec defining a
stylesheet language, because it's chartered to define a stylesheet
language.  However much I sympathize with your desire to see the
transformation language separated out, it's hard to make a case for this
within the XSL WG given the current XSL charter.

James

[Ed Nixon expands on James' comment:] I think it's very important to remember that the dialogues, questions, answers and problems that are 'vented' on this list are far from being representative of the interests and concerns of the end-user community that will ultimately try to use XSL. 

You folks are generally technically adept professionals who, based on what I read here, already implementing solutions based on XSL. In addition, it's pretty clear that you are having some problems absorbing aspects of the paradigm shift that XSL represents. 

These experiments (and implementations) are great because they provide an useful basis for validating the specification. However, the rules (which I don't see anyone arguing about) are that the specification is in *draft*, not complete and therefore not suitable for production work. To me, being able to say something is "100% conformant" with XSL at this point is absurd: XSL does not exist as something that can be conformed with. Besides, does anyone really believe down deep that "100% conformance" is a major preocupation of Microsoft or it's orbitting asteroids? Conformance is in the eye of the beholder. From what I see, there are already enough haphazardly documented variants and extensions of the tree-transformation part of the specification; why would we want to multiply this by the probability of two?

When Paul raised the question of splitting the  XSL work on this list a number of months ago, I raised the concern that doing so might take the major vendors and implementors 'off the hook' with respect to implementing FO's. Paul's response, as I remember it, was that all of the work would/could still be completed at the same time. My concern still remains. 'Expediency' seems to be a small price to pay for increasing the odds that, in fact, it all gets done at the same time.

I think the best use of our time on the list might be to get back to the checking and validation of the spec. from our side and improving the readability and comprehensibility of the spec. on the part of the W3C folks. E.g., more examples, more FAQs, more mid- and high-level summaries and explanations, more and better experimental implementations.

...edN

<<application/ms-tnef>>