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]
Other format: [Raw text]

RE: XSLT 2.0 question



Michael Kay said
>> For many reasons too voluminous to go into here I can't
>> change the structure
>> of how stylesheets are run in this app

>Are you serious? You want the XSLT language specification changed because
>you can't change the structure of your app?

now waitaminute! my admittedly slipshod email-english  can't have betrayed
me so badly, what I wanted to know was if it was possible, not suggesting
that the spec should be changed. although now that I think of it, that is
what people do isn't it, they suggest specs should be changed because they
can't do things they way they want to, this however is not what I'm asking
for here. What I was asking about pertained to xslt 2.0, I was uncertain if
there existed something in the spec that I'd overlooked which would allow me
to do the following(or if not that, if anything had considered it):

let's suppose you write an application that applies xslt's against xml
files.
the xml file has inside of it a processing instruction linking to another
xslt or a number of such,
it also has an embedded xslt.
The xml file is written, and the writer has no knowledge of what your
application's xslt's are, how does one handle this??
Could handle it from the application itself, could perhaps handle it with a
pipeline definition, is there anyway to handle it in the application level
xslt? Jeni said no, and I figured no anyway so the answer is NO!!

the desire to handle this is different than asking for dynamic xslt loading
through import, like people are always asking for <xsl:import
href="{$file}"/> because there is a parser connection between the embedded
and linked stylesheet already, isn't there?
(I've already decided that this just does not exist, so this now becomes a
wishList email, say for xslt 3.0)
if you had a default precedence for stylesheets, that is to say you have an
application stylesheet which takes precedence over the other two, the linked
stylesheet takes precedence over the embedded, with the stylesheets in order
of precedence being treated like imported stylesheets, the application
stylesheet is considered to import the linked stylesheet(although ignoring
processing instructions that lead to .css stylesheets) and the embedded
stylesheet is considered as being imported into the last of the linked
stylesheets.
IF this was acceptable behavior then would it be possible to switch
processing precedence declaratively from
 DEFAULT:  ApplicationStylesheet
			LinkedStylesheet
				EmbeddedStylesheet

To
  EmbeddedStylesheet
	LinkedStylesheet
		ApplicationStylesheet

or
  LinkedStylesheet .... and so on? I know there's probably some deep reason
why this could never be and I'm missing it. One reason I guess that I got on
this is I've never liked embedded stylesheets cause I never saw the use of
them(personal likes and dislikes), but I've always been secretly hoping to
finding a cool way to use them.

okay I'm hoping I got what I wanted to say out clearly.
Aside from main content of the email maybe everyone can give me posting
hints? I swear I feel like the most perpetually misunderstood fool
sometimes, I'm not grouchy, I'm sitting here blushing.


 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]