docbook-apps

  • 1.  seek best practice using xinclude and imagedata/fileref

    Posted 10-06-2018 23:01
    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



  • 2.  Re: [docbook-apps] seek best practice using xinclude and imagedata/fileref

    Posted 10-07-2018 06:38
    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.



  • 3.  Re: [docbook-apps] seek best practice using xinclude and imagedata/fileref

    Posted 10-08-2018 16:14
    There is also a section in my book specifically on using catalogs and
    entityrefs as a means of indirection for graphics:

    http://www.sagehill.net/docbookxsl/GraphicsLocations.html

    This is useful if your goal is to avoid having to edit the XML documents
    when you change image file locations.

    Bob Stayton
    Sagehill Enterprises
    bobs@sagehill.net

    On 10/6/2018 11:37 PM, Dave Pawson wrote:
    > 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
    >>
    >>
    >