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] | [List Home]

Subject: Re: [docbook-apps] XSL customisation layer: directory structure


oXygen supports working with modules. We introduced (since version 8 I 
believe) the concept of a validation scenarios where one can specify 
that the main file, in this case docbook.xsl should be validated instead 
of the current file, and thus the module gets validated in the context 
it is used from and not as a standalone stylesheet.

For more information please see:

Best Regards,
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger

Bergfrid Skaara wrote:
> Hi,
> I'm using oXygen XML Editor 10.0 and can confirm this behavior there.
> My 2 cents is as follows:
> The issue is similar to the idref validation errors you get with
> modular DocBook XML. The individual fragments will not validate, but
> the main document pulling them in, will.
> The red validation error indicators in the XSL files has nothing to do
> with the location of the files: simply open one of the stock XSL files
> (except docbook.xsl) in oXygen and you will observe the same red lines
> there when a template calls a named template or references a global
> parameter or variable.
> In sum, this is a modularization issue and I guess you should see
> similar behavior in other validating XML editors.
> Best regards,
> Bergfrid Skaara
> On Fri, Apr 3, 2009 at 1:26 AM, Jennifer Moore
> <jennifer@uncharted-worlds.org> wrote:
>> Just realised I'd only sent this to Bob, when I meant to send it to the
>> group, in case anyone else had a similar problem...
>> ====
>> Thanks Bob!  That helped - I've made sense of it now.
>> I was mixing up two kinds of error.
>> In my new files with custom templates, oXygen was giving me the warnings
>> about (other) templates not existing, etc. via its "little red lines".
>> I mistakenly thought those were telling me what was stopping the
>> transformation from working.
>> But in fact, the transformation was only being stopped by a place where
>> I'd still (or again - after all this moving stuff about :-) ) got the
>> wrong relative address in the entity tag.  As soon as I fixed that, the
>> transformation worked again.
>> oXygen is _still_ giving me little-red-line warnings about missing
>> templates, but it seems to me now that I can just ignore those, in that
>> they're only true within the context of one file by itself.  (i.e. that
>> file by itself "doesn't know" that by the time it has to do anything,
>> I'll have imported docbook.xsl as well.)
>> Please correct me if I'm wrong in my interpretation there...
>> Other than that, seems like everything's working OK now - it's just
>> minorly annoying to be stuck with the irrelevant red lines, which
>> _usually_ mean something I'd want to pay attention to.  (Or maybe
>> there's a way of telling oXygen not to worry in this context?  in which
>> case that would be useful...)  (mind you this is only oXygen 8.2, not
>> the latest, so maybe they _have_ done that in a later one...)
>> Jennifer
>> Bob Stayton wrote:
>>> Hi Jennifer,
>>> This is curious.  There are almost no constraints on where the various
>>> stylesheet modules are located.  They can be scattered over many
>>> directories, as the DocBook XSL files are.  You could even import with an
>>> http URL.
>>> In general, a relative import address is taken as relative to the file
>>> that contains the xsl:import element. That keeps things pretty simple,
>>> fortunately. For each import, you just have to confirm the location relative
>>> to that file.  Once you import the DocBook docbook.xsl file, it will handle
>>> its own relative imports.
>>> Arranging your customization files outside the distributed files is good
>>> practice, not foolish, and highly recommended for easy maintenance and
>>> updates.  But clearly something is going wrong with your setup.  I can't
>>> tell what it is from the information so far. Can you provide more details?
>>> That kind of error means some XSL files are not being read for some reason.
>>> Are there no other error messages?
>>> Bob Stayton
>>> Sagehill Enterprises
>>> bobs@sagehill.net
>>> ----- Original Message ----- From: "Jennifer Moore"
>>> <jennifer@uncharted-worlds.org>
>>> To: <docbook-apps@lists.oasis-open.org>
>>> Sent: Monday, March 30, 2009 2:12 PM
>>> Subject: [docbook-apps] XSL customisation layer: directory structure
>>>> Hello all
>>>> (and a belated thanks to Mauritz and Bob for helpful replies to my last
>>>> question, which I seem to have neglected to report back on at the time -
>>>> have got link title attributes working nicely now via XLink.)
>>>> I'd been thinking I'd like to learn how to do a custom layer of XSL, so
>>>> as to tweak my HTML output a bit.
>>>> I've successfully made an initial file as described in Bob's book
>>>> (example 9.1 here:
>>>> http://www.sagehill.net/docbookxsl/CustomMethods.html#CustomizationLayer)
>>>> and begun to create my own templates, of which I currently have a couple
>>>> in separate files, imported e.g. like this to the main one:
>>>> <xsl:import href="emphasis_custom.xsl"/>
>>>> Well, I was getting on OK until I got the bright idea that perhaps it
>>>> would be best to move the various custom files into a separate directory
>>>> rather than having them mixed in with the default ones.  At that point
>>>> things stopped working.  So now I am wondering if in fact that was a foolish
>>>> idea :-)
>>>> Is it _possible_ to use different directories, and if so, what do I need
>>>> to do to make the relative addressing work so the templates can "see" each
>>>> other?
>>>> Or do the custom files have to be in the same directory as the docbook
>>>> default ones?  and in that case, is there any particular naming convention,
>>>> for making the custom files easily identifiable if & when I upgrade and want
>>>> to copy them over?
>>>> For background, here's what I did:
>>>> First I had set up a subdirectory of the html directory, and made my "top
>>>> level" custom file call docbook like this:
>>>> <xsl:import href="../docbook.xsl"/>
>>>> It wasn't happy till I corrected the relative addressing for
>>>> <!ENTITY % common.entities SYSTEM "../common/entities.ent">
>>>> %common.entities;
>>>> ]>
>>>> by making it
>>>> <!DOCTYPE xsl:stylesheet [
>>>> <!ENTITY % common.entities SYSTEM "../../common/entities.ent">
>>>> %common.entities;
>>>> ]>
>>>> Then I got errors like "No template exists named anchor".
>>>> Then as an alternative I tried making a custom directory at the same
>>>> level as the html directory, with
>>>> <xsl:import href="../html/docbook.xsl"/>
>>>> and changing the ENTITY thing above back to what it was before.
>>>> But I was still getting error messages of "No template exists named ...".
>>>> It seemed like one template could only "see" another if they were in the
>>>> same directory.
>>>> (though oddly enough it doesn't seem to mind having the "main" custom
>>>> layer file in another directory - but then at present that one isn't calling
>>>> any templates, only importing others that do.)
>>>> Thanks in advance for clues.
>>>> Jennifer
>>>> --
>>>> www.uncharted-worlds.org/blog/
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
>>>> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
>> --
>> www.uncharted-worlds.org/blog/
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
>> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docbook-apps-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: docbook-apps-help@lists.oasis-open.org

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