OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

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


Subject: DOCBOOK: Re: Concrete proposal for #480954: Extend textobject toinsert external files


/ Elliotte Rusty Harold <elharo@metalab.unc.edu> was heard to say:
| At 12:54 PM -0500 11/12/01, Norman Walsh wrote:
| 
| >In fact, the only reasons I want to pursue this at all, instead of
| >simply saying "use XInclude" are that (1) XInclude is not a REC,
| 
| Which do you think is more likely to be done first? XInclude or
| Docbook 5? My current understanding is that XInclude is moving forward.

I think this extension could find its way into DocBook 4.2 which I
hope we can publish fairly soon.

| >(2)
| >whether you do validation before or after XInclude is unclear
| 
| Not really once you realize that validation is defined against XML
| 1.0, and XML 1.0 doesn't know squat about XInclude. Pass a document

Right. I'm aware of that. And as you pointed out, for parse=text, it's
really not an issue.

But, using XInclude would raise at least the following issues:

1. Can we limit it to parse=text. I don't think so. If we refer
   normatively to XInclude, we have to accept XInclude semantics.

2. Where would we allow xinclude elements? For the task at hand, we'd
   probably only want to allow them in a very small number of places,
   but as soon as we include it, no pun intended, people will want
   parse=xml and can I put it anywhere, please?

4. One possibility would be to allow xinclude inside textobject, instead
   of giving textobject fileref and entityref attributes.

5. But within the framework of DocBook, fileref and entityref attributes are
   the "natural" way to provide this functionality. Is the existence of
   XInclude a sufficiently strong motivator to provide the functionality
   that way? It might be, given the semantic issues of encodings and such,
   but I'm not sure.

6. If we allow it anywhere, what do we say or do about validation
   when parse=xml?

And I wonder if it isn't reasonable to do both, to provide the textobject
extensions now and XInclude support as well. Either now or later.

| >  (3)
| >XInclude will force us to add namespace support for a feature that
| >really should be part of the core DTD (as opposed to a module like
| >MathML).
| 
| It only really requires us to declare the XInclude namespace. It does
| not require use to define a DocBook namespace.

Right. But even that is tricky since DTDs and namespaces don't play
together terribly well.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | Fast. Cheap. Well. Pick two.
http://www.oasis-open.org/docbook/ | 
Chair, DocBook Technical Committee |


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


Powered by eList eXpress LLC