[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] XSL customisation layer: directory structure
Having just developed a big project with many, many interdependent modules, I can confirm that oXygen's validation scenarios are a superb solution! John On Apr 13, 2009, at 5:03 AM, George Cristian Bina wrote: > Hi, > > 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: > http://www.oxygenxml.com/doc/ug-oxygen/validation-scenario.html > > Best Regards, > George > -- > George Cristian Bina > <oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger > http://www.oxygenxml.com > > 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 > > --------------------------------------------------------------------- > 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]