[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: Issues of practicality and scale-up

---

---

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

---