Re: Relative Paths?

[Galen Boyer <galenboyer@hotpop.com>]

On Wed, 19 Mar 2003, pgrosso@arbortext.com wrote:
> At 10:28 2003 03 19 -0800, Galen Boyer wrote:
>>On Wed, 19 Mar 2003, pgrosso@arbortext.com wrote:
>>> Relative paths are relative to the base URI which--in the
>>> absence of other info (such as in your case)--
>>
>>Well, I could cut-n-paste the whole thing in, but that would piss alot
>>of people off.
>>
>>> is the resource in which they were found.
>>> 
>>> So in the first case, images-db/schema_picture.bmp is relative
>>> to dbms/docs/database.xmldoc and in the second case it is
>>> relative to your document.
>>
>>So, in a subdocument, I must either do fully qualified paths or make
>>relative references from the parent document?
> 
> That's not how I'd say it.  In particular, I don't know what
> you mean by "make relative references from the parent document."
> 
> In each entity, paths should be relative to the location of that
> entity.

Suppose I'm editing a subdocument.  In the path to the object I am
trying to reference (an image object) I have to have the knowledge of
where this particular subdocument's parent document is.  I can't just
reference the image object with a relative path to the current edited
subdocument.

This means, I can't just ask people to work on a particular subsection
of a book and not really worry about the contruction of the book.  They
need to know where the book's source is.

It also means that if I try to restructure the book, maybe move from one
file per sect1 into one file for all section tags, I would have to
be cognizant of the parent as well as the children.

Its restricts you a little further.  Thats okay though.  The problem for
me is that I've only used docbook very sparingly before and I'm
basically turning my entire company's development team onto it.  So, I'm
designing what the documentation structure will be, where in CVS files
will sit, what calls what and how much docbook editing will people need
to know.  Right now, I'm constantly reworking the structure until it
seems to make sense, and then, I'll roll it out.  I'd rather start with
the team not having to know much of docbook.  Instead, be given an
already tagged file.  An already tagged file is pretty much
self-explanatory.  Tagging a file means you have to be able to translate
each definition of something to docbook's.  Coming from Word, this is
even harder to get across cause you have to wrestle the formatting
capabilities from their minds.

> But since you did something and it works, I gather you figured it out.
> 
>>    Hm... (Gives it a go)
>>
>>Yep, that works.  Thanks, I have a way to proceed.
>>
>>The bummer is that a need to restructure a book that includes all
>>sorts of subdocuments wouldn't involve just reworking xml tags, but
>>also the data within those chapters and subsections.  Well, I guess it
>>is attribute data of the xml tags, and not actual data.  Hm...
>>
>>Is there anyway for a subdocument to use a predefined entity that
>>represents a path and prepend that to the appropriate files to be
>>referenced. (ie, in a subdocument, and continuing with my image
>>example, I tried the following which failed, but the idea is what I'd
>>like to accomplish)
>>
>><imageobject>
>>   <imagedata
>>   fileref="&database_doc_dir;/images-db/schema_picture.bmp"/>
>></imageobject>
> 
> 
> Something like that could be made to work.  
> 
> See also XML Base [1], though not all tools support it.
> 
> paul
> 
> [1] http://www.w3.org/TR/xmlbase/

Okay, now I'm in over my head.  I'm just trying to take advantage of the
docbook dtd.  What you are showing me seems to require a level of
expertise with XML that I haven't reached, yet, anyways.

-- 
Galen deForest Boyer
Sweet dreams and flying machines in pieces on the ground.