Re: DOCBOOK: Re: [docbook-tc] DocBook Technical Committee MeetingMinutes: 19 Nov 2002

[Bob Stayton <bobs at caldera dot com>]

On Tue, Nov 19, 2002 at 05:34:10PM -0600, Paul Grosso wrote:
> At 14:40 2002 11 19 -0500, Norman Walsh wrote:
> 
> >| 6. Instance-based cross-reference text
> >
> >This is on the agenda for Paul to consider use cases. Unfortunately,
> >Paul isn't here this week.
> >
> >ACTION: Bob to discuss with Paul for next month. Plan to close next month.
> 
> Oops, what was/am I supposed to do here?  Someone remind me what
> this is about please.

I'll send you a separate mail about this.

> 
> >|     615587 Support xml:base
> >
> >Any object to adding xml:base to the common attributes? None.
> 
> Hmm, no discussion?  I'd have had lots of questions.
> 
> Just what is the point of xml:base?  

This is motivated by the desire to accomodate Xincludes,
but it also can be added by hand to a document.

You probably already know this, but I'll summarize it anyway.
When an XInclude is processed, the included content may
have references that are relative to the included
document.  Simply including them would make it look like
those references are relative to the including document.
The Xinclude processor inserts an xml:base attribute in the
containing element.  The xml:base is set to the href of the
included document so that a processor knows how to resolve
the included references.

> Having xml:base is
> only useful if there are relative URIs within scope, so
> it's important to answer just what values are supposed to 
> be affected by xml:base.
> 
> So just what things in DocBook are affected by xml:base?
> 
> Does xml:base affect the value of the fileref attribute?
> What about ulink's url attribute?  They are both just CDATA,
> so how is an application supposed to know whether they should
> be affected?  Yet users will certainly expect them to be.

Yes, fileref and ulink's url attribute would be affected,
if they are relative references.  

It shouldn't matter how a reference is specified.
An application doesn't know an attribute is an external file
reference until it is asked to open it up. 
Any such lookup triggered from within the context of an xml:base
value should take the containing xml:base into account.

If the application is generating XML output, it should pass
the xml:base value through so that downstream processors
such as an FO processor can use it when it opens the file.

> 
> What else, if anything, will be affected?  Maybe xincludes,
> but the next item says we rejected supporting xinclude.

We rejected adding xincludes to the DTD because it is
pretty impossible to write content models with an
optional xinclude element that can include required elements.
Essentially validation must take place after xincludes
are resolved.  But an xml:base attribute on an element
containing an xinclude will still affect the resolution
of the xinclude that takes place before validation or
before further processing.

> >
> >|     615588 Support XInclude
> >
> >BS: I don't think it's possible because you can potentially XInclude
> >required elements.
> >
> >Rejected. You should do XInclude before DTD validation.


-- 

Bob Stayton                                 400 Encinal Street
Publications Architect                      Santa Cruz, CA  95060
Technical Publications                      voice: (831) 427-7796
The SCO Group                               fax:   (831) 429-1887
                                            email: bobs@sco.com