This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: efficient filtering of XML files. ( XML!=content && XSLT!=presentation )?


> Dan Morrison wrote:
> Personally I've been a stickler for Content & Presentation being
> abstracted from each other as much as possible, and generally add
> Logic/Navigation as a third independant entity.

Agreed. I was just saying that some tend to think XSL=Presentation and
therefore consider XSL documents to be where to dump everything-but-Content,
overlooking the fact that there is quite a bit of quantifiable data mixed
in with their presentational logic, data that is often ripe for
inclusion in XML (of course, not all mixed up in the content data).

> While I agree that hand-coding tiny variations is bad, I've been
> achieving results using XSL layout 'libraries' and xsl:include, so only
> the unique bits end up in a new file.

But given the dreadful limitation on xsl:include and xsl:import
(href="fixed_URI_string"), there's not much advantage to using it
in this manner, is there? I'm guilty of it, myself, but I've often
thought there was no point in using xsl:include except to just
break up a large stylesheet into smaller files.

> But how does this miss the point? As I see it, the alternative is to
> 'contaminate' the XSL with lots of conditionals. Now that's messy.

The point that was being missed was that with XSL you have at your
disposal any number of hierarchical data sources from which you can obtain
information that helps you build a new hierarchical data structure. To
restrict the source data repositories to house only "content" is to
overlook the numerous possibilities offered by XML and XSL -- lots of
information can be put into the source trees, data that the XSL can use as
cues as to how to go about building up the result tree.

xsl:apply-templates can be very powerful when used to process, for
example, a source tree consisting of a purely structural description of a
web site, and secondary source trees (retrieved via document()) consisting
of presentational variables (colors, text styles, image names and
attributes) referenced by the structural tree.

I can see how conditionals can get messy, but templates that match
different things, or spaghetti choose-when'ing ... there's not much
difference! You have to draw a line and say "in this situation I want to
do a,b,c and in this other situation I want to do x,y,z" ... it's just
better to have as few as those as possible, IMO. Quantifying and acting on
presentational data alongside, but separate from, the content data, is one
way to go about that.

> Nahraharis "100 times" seems to require a re-think tho, If I understand
> this means 100 unique XSLs!

Agreed.

> We know that XML+XSL=Presentation of Data, we know that
> XML+XSL[2]=Alternative Presentation of Data. Has anyone got a resource
> on the thinking behind how to glue this together?

I'm saying about as much as I can without posting the source code for my
company's closed-source product. :)


   - 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]