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] seek best practice using xinclude and imagedata/fileref


You might like a level of indirection provided by xml catalog.
http://www.sagehill.net/docbookxsl/WriteCatalog.html

Particularly if you think you may modify the layout as the system develops?

HTH
On Sun, 7 Oct 2018 at 00:01, Otto Hirr <ottohirr@gmail.com> wrote:
>
> Greetings,
>
> I'm looking for best practice on how to modularize using xinclude and access image files using imagedata/fileref.
>
> I have a tree of resources, mostly various image files, such as scanned documents.
> These are in a rather large tree of folders based upon either a kind of date/time of occurrence or by topic.
>
> These need to be composed to tell a story.
>
> The textual content, along with inclusion of images, is placed in docbook xml files that are also scattered around the tree.
>
> Some of the store line is time based and will have dcbkxml interspersed in say the chronological folders.
> So a given year story line dcbkxml will be xinclude'ing subfolder dcbkxml files, which have textual components and imagedata stored in current directory or sub*directories.
>
> Other story lines are topical and span across the time line, hence the dcbkxml will be in a Topic/subtopic folder, but needs access to image data spread across the time line folders.
>
> After various attempts, I had settled on simply setting the xml:base to be the root location of the whole tree, with a path from the top of the file-system hierarchy.
>
> The enabled a simple referencing system:
>
> for  xinclude/href the path simply specified the relative location below the  xml:base location,
> for  imagedata/fileref the path likewise simply specified the relative location below the  xml:base location
>
> It has been suggested that this is a less robust method, and one alternative was to suggest setting a  xml:base using relative paths.
>
> At the time the method was being considered, the tree was not well defined, and undergoing some changes.
>
> To have used relative paths, e.g.  xml:base="../../" would present problems if a part of the tree needed to move.
>
> To do a global change across xml files of a specified relative path from the  xml:base would be easy.
> To do a global change across xml files of a specified relative path in the form of "../../" would be problematic.
>
> The downside of the this whole approach is the  xml:base is in every dcbkxml file, yet it is the same, so easy to change, i.e. global replacement, should the root need to be relocated.
>
> What is the best practice for managing this?
>
> Best regards,
>
> ..Otto
>
>


-- 
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.


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