RE: Stylesheet portability (Long) (Was: [xsl] XSLT 1.1 comments)

Subject: RE: Stylesheet portability (Long) (Was: [xsl] XSLT 1.1 comments)
From: Joshua Allen <joshuaa@xxxxxxxxxxxxx>
Date: Fri, 16 Feb 2001 16:45:17 -0800
David Marston Wrote:

>Francis Norton made a remark about a lint-like utility for stylesheets 
>that has inspired some discussion. I think anything that passed cleanly 
>would be unrealistically constrained. To summarize, stylesheet portability 

Well, people write portable stylesheets all the time, so if their
stylesheets didn't pass cleanly, that would mean the tool was wrong.
I'm reading your statement to imply that "portable stylesheets are
impossible to write except in unrealistic test cases."  I'm guessing that
is an incorrect interpretation of what you said?

>David Carlisle wrote: 
>>But for me, a portable stylesheet doesn't use keys... 

>I find that absurd! It's going to be hard enough to say that a 

Yeah, I have seen this a lot though, because people use xt,
assuming that James Clark's involvement will mean it is more
conformant and less prone to traps than the big vendors. 

Unfortunately in the case of keys, this leads to people
missing a nice tool that is totally conformant and otherwise

>up-to-date (but still conforms to the original XSLT 1.0)? What if 
>vendor A insists that the spec is perfectly clear in some area where 
>vendor B says there's a gray area? I think that a portable stylesheet 

Right, this is a difficulty with a lint tool, but also why
I always insist people should test on multiple processors.
When people test their style sheets on multiple processors,
they end up posting here, and then all the vendors talk about
their assumptions, and things get better.  (Isn't this how
node-set got into MSXML3?)  Of course, this isn't a selfish
technique to get the users to debug our processors, because the
users benefit too.  For one, the users get a better understanding
of what is XSLT and what is "extra cruft", and I think this
leads to better designs.  Also, as Java showed us, even if
people are not convinced that code they write will port
flawlessly, they want to feel that their *skills* can be applied
on multiple platforms if necessary.  So each time they test
XSLT on multiple processors and it works, there is a nice dose
of validation that "I could ditch this job and get another job
on any platform if I wanted." :-)  There are other benefits,

>The above squeezes away various exceptions and details. I wanted it 
>to serve as a scoping vehicle for the notion of assessing stylesheet 
>portability. To see more about the OASIS test suite effort, go to 

I don't think the discussion of "assessing stylesheet portability"
has to be so intellectual, though.  I mean, I can just run my
XSLT through the major processors and know that it's portable;
end of discussion.  At the same time, as the users feedback
displeasure at lack of portability and vendors stay in the feedback
loop, the amount of intellectual introspection that vendors
have to do should be reduced, since portability will be even easier.

>really wants to write XStyLinT(TM), please consider joining the

Anyway, you make a good point that a totally comprehensive
XStyLinT(TM) would be very tedious.  One that caught the major
pitfalls ought to be fairly easy, though, but for me
it's just as easy to test..

 XSL-List info and archive:

Current Thread