Subject: Re: efficient filtering of XML files. ( XML!=content && XSLT!=presentation )? From: Mike Brown <mike@xxxxxxxx> Date: Tue, 4 Apr 2000 22:07:22 -0600 (MDT) |
> 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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: efficient filtering of XML file, Dan Morrison | Thread | Re: efficient filtering of XML file, David Carlisle |
tag names, Alankar Chowdhury | Date | Re: tag names, Steve Tinney |
Month |