RE: Issues of practicality and scale-up

Subject: RE: Issues of practicality and scale-up
From: "Jonathan Borden" <jborden@xxxxxxxxxxxx>
Date: Sat, 6 May 2000 10:26:58 -0400
Mike,

That was a really excellent response. I think people need to realize that
XSL hacking will have its own tricks and techniques and the fact that you
may find some operations difficult doesn't mean the language is at fault.
The extension mechanism allows you to 'escape' to a conventional programming
language, and as always some problems will be best solved procedurally, so
pick your tools wisely and remember that just because you have found a shiny
new hammer, not every problem becomes a nail. On the other hand there are an
awfully large number of nails lying around waiting to be hit :-))

Jonathan Borden

Mike Brown wrote:
>
>
> > 'or' is exclusive-only
>
> I'm not sure this is a disadvantage. It seems pretty intuitive to me.
>
> > 'translate()' is *horribly* weak and un-useful
>
> ...probably because, as I was told by James Clark in an explanation of why
> substring functions weren't available, the committees couldn't even agree
> upon what a character was before the July 1999 working drafts.
>
> > no easy ways to check if 'element' is a member of 'list'
>
> There are vendor-specific extension functions for this, or you
> can do it with this not-obvious but not-too-difficult example:
>
> <xsl:variable name="nodeToTest" select="/some/single/node"/>
> <xsl:variable name="nodeList" select="/some/node/set"/>
> <xsl:variable name="sharedNodeID">
>   <xsl:for-each select="$nodeList">
>     <xsl:if test="generate-id($nodeToTest)=generate-id(.)">
>       <xsl:value-of select="generate-id(.)"/>
>     </xsl:if>
>   </xsl:for-each>
> </xsl:variable>
> <xsl:choose>
>   <xsl:when test="$sharedNodeID">node is in the list</xsl:when>
>   <xsl:otherwise>node is not in the list</xsl:otherwise>
> </xsl:choose>
>
> > 3. The N*M problem.
>
> From here on down, all your questions are related and the problems
> are mostly resolved by changing your view of what you think of as
> "data" and what you think of as presentational components that belong
> in a stylesheet. This was a topic of discussion about a month, maybe a
> month and a half ago.
>
> > Suppose you want to allow people to apply personal preferences to the
> > display of a document.  Suppose there are N such preference types.
>
> This is information you can collect and put into XML documents.
>
> > Also you want people to view the doc in different mediums: over the
> > web, on their fancy-cell-phone, or whatever.  You have M such media.  It
> > seems that now you have to make N*M different stylesheets to accomodate
> > these display representations of the same document.
>
> Components of desired output documents can also be modeled with XML and
> XHTML. The stylesheets can be devoted mainly to presentation *logic*, and
> most of the actual presentational content can be obtained from XML/XHTML.
> The document() function is very, very useful!
>
> > What happens when many of the stylesheets have major
> similarities?  If you
> > want to make a change, how do you avoid having to propogate the changes
> > through each stylesheet?
>
> Put that stuff out in XML, not in your stylesheet, and have the stylesheet
> go look up the information it needs based on user preferences, which is
> also going to be in the XML.
>
> > What happens when you want to internationalize to L different languages?
>
> Again, have your stylesheet just be code that goes and gets what it needs
> from the XML/XHTML.
>
> > 4.  Code reuse and refactoring.
> >
> > The problem with [one template with many conditionals]
> > is that the code gets nasty and unreadable very quickly.
> > The problems with [many templates] are that you often replicate code
>
> I prefer many templates. When I need to replicate code, I use calls to
> named templates, sometimes with parameters if there are slight variations
> that need to be accounted for. Named templates provide the equivalent of
> subroutines or private methods.
>
> > and there is no 'otherwise' clause to catch things that fall through
> > the tests.
>
> Which tests, the match attributes on xsl:template elements? Say you want
> to process 'foo' elements, and you want to have one template for when
> foo's 'name' attribute is 'bar', one template for when it's 'baz', and one
> template for all other 'foo's:
>
> <xsl:template match="foo[@name='bar']"/>
> <xsl:template match="foo[@name='baz']"/>
> <xsl:template match="foo"/>
>
> And these are in addition to the built-in template that matches "*" (any
> element). The templates with the greater degree of specificity will have
> higher priority for matching.
>
> > Have people been able to move towards dynamically-generated XSL
> so that some
> > of the contextual complexities of the above issues can be automated?
>
> I would guess that you are not quantifying enough of your data in XML.
> Presentational data is data, too. Put it in separate XML documents and let
> your stylesheet use the document() function to access it and merge it all
> together with your "data data".
>
> At some point, though, you have things that need to be dynamically
> generated, and for this my solution for now has been to just bite the
> bullet and write custom templates. But I've abstracted 80% of the
> commonalities out of these templates and modeled as much data as I can in
> XML, cutting down the size and redundancy of the custom XSL templates by
> orders of magnitude.
>
> Now, if you were naughty and neglected to mention that you are restricted
> to using the stock MSXML that comes with IE5, ignore everything I've said
> here. :)
>
>    - Mike
> ___________________________________________________________
> Mike J. Brown, software engineer, Webb Interactive Services
> XML/XSL stuff: http://www.skew.org/    http://www.webb.net/
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread