OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: DOCBOOK-APPS: variable import hrefs?


Norman Walsh writes:
> / Mark Johnson <mark@phy.duke.edu> was heard to say:
> | Norman Walsh writes:
> | > / Mark Johnson <mark@phy.duke.edu> was heard to say:
> | > |
> | > | For xsl stylesheets, is there a way to set import hrefs at runtime?
> | > |
> | > | i.e. something having this effect:
> | > |   <xsl:import href="{$my_stylesheet_home}/xhtml/docbook.xsl"/>
> | > 
> | > No, you can't do that.
> | > 
> | > The catalog-based URIResolver class would let you redirect this in a
> | > catalog. Would that solve your problem, or is there something deeper
> | > going on?
> | > 
> | That'll work if we implement the user $HOME/.catalog part of the lsb
> | proposal:
> | 
> |  http://www.linuxbase.org/spec/gLSB/gLSB/sgmlr003.html
> 
> The catalog classes I'm trying to get published use a
> CatalogManager.properties file to set default values for things like
> what catalogs to load.
> 
> If you want something more dynamic than that, uhm, what do you want,
> exactly?

I want it all. Everything. Now.

OK. Here's an example that illustrates the situation:

On a linux system --

Suppose somebody, umm let's call her Norma, is processing WebSite DTD
source files with the website stylesheets.

Furthermore, Norma is a hardcore xt user (or only has access to xt -
same thing). She doesn't know any xsl and don't want to know any. 

Her sysadmin is really on the ball, so he installed the latest DocBook
XSL stylesheets, version 1.29, right alongside the previous version,
1.24. The installation procedure arranges things so that the website
stylesheets now import files from version 1.29, NOT version
1.24. Since XT doesn't work with the new stylesheets, she's out of
luck. 

The sysadmin won't help her out by changing the "default" DocBook XSL
styelsheets because his power users are happy with the latest xalan,
or whatever, and really gotta have version 1.29.

Norma is now stuck. And not happy, either.

However, none of this would be a problem if she could do something
equivalent to setting

 MY_STYLESHEET_HOME="pointer to version 1.24"

which would get evaluated at run time in the import statement in
website.xsl:

 <xsl:import href="{$MY_STYLESHEET_HOME}/xhtml/docbook.xsl"/>

which would definitely do the trick.


Despite the dopey story line, I'm quite serious. This issue is bound
to arise again and again in different settings. 

Of course, this capability would be useful in other ways, as well.



Here's my (fuzzy) take on a catalog-based solution:

If:

  the appropriate catalog mechanism were in place that located
  stylesheet versions,
 
- and -

  the import URI used some sort of abstract identifier

- and -

  the parsing setup gave $HOME/.catalog a higher priority than
  the system catalogs

Then:

  the user's $HOME/.catalog could tell the parser to look at whatever
  version the user wanted it to point to.

Cool, eh?


But hey, I'm no expert. For all I know, what I'm asking for could be

(a.) already in the works
(b.) ridiculous, unseemly
(c.) already solved, (my ignorance is the problem)
(d.) profound, insightful, visionary

I hope it's (d.), but I doubt it.

Does that all make sense? The concept is straightforward, but the
implementation may not be.
  
Opinions?? 

Thanks,
Mark

> 
>                                         Be seeing you, norm
> 
> -- 
> Norman Walsh <ndw@nwalsh.com> | What is familiar is what we are used
> http://nwalsh.com/            | to; and what we are used to is most
>                               | difficult to 'Know'--that is, to see as
>                               | a problem; that is, to see as strange,
>                               | as distant, as 'outside us'.--Nietzsche


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC