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

[Norman Walsh <ndw@nwalsh.com>]

/ Bob Stayton <bobs@caldera.com> was heard to say:
| > From: Norman Walsh <ndw@nwalsh.com>
[...]
| > If we do that, I suggest that we change the content model of
| > inlinemediaobject to:
| > 
| > inlinemediaobject ::=
| > (objectinfo?,
| >  textobject+|
| >  ((videoobject|audioobject|imageobject),
| >  (videoobject|audioobject|imageobject|textobject)*))
[...]
| Can you clarify the processing expectations of these two
| variations?  The current linespecific hack is used to pull
| in code samples as raw image data, essentially CDATA
| sections, right?  I presume that would be the way the first
| variation is handled (the one without a graphic object).

Right.

| In the second variation, the textobject serves
| as an alternative to the graphic elements for non-
| graphical presentation contexts.
| It is presumed to be Docbook markup, and
| processed with apply-templates in XSL.  Moving the
| content from within the element to a file or
| entity ref wouldn't change that.

Right. Well, there's no way to move it out of the element. You could
put the text in a file and put an entity ref inside the element, but
that would still have the content inside the element.

| These seem like two very different animals, and could
| lead to some confusion in how they are used, no?

Hmm. Perhaps, but I hope we can make it pretty clear.

| The RFE mentions adding attributes to distinguish
| these two cases.  Were you going to add something
| like format="linespecific" to textobject to handle
| that?  Does this affect the content model of textobject?

I had imagined that the 'fileref' or 'entityref' attributes would be
sufficient. In any context,

  <textobject fileref='somefile.txt'/>

would insert the contents of somefile.txt as unparsed text (to
whatever extent that textobject is used). Likewise, in any context:

  <textobject><!-- some content --></textobject>

would insert the (styled) contents of the textobject (to whatever
extent that textobject is used).

Using both:

  <textobject fileref='somefile.txt'><!-- some content --></textobject>

would be an error. The, uh, content would be selected, I think, and
the reference ignored.

| I agree we need something other than the hack, but I
| want the semantics to be unambiguous.

Certainly. What we're really doing is promoting a complete hack to a
marginal feature. :-)

I think I'd be opposed to adding a new element (<transclusion> or
something) for this purpose. That would be essentially duplicating the
functionality of XInclude.

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, (2)
whether you do validation before or after XInclude is unclear, and (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).

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | Noble patterns must be fetched
http://www.oasis-open.org/docbook/ | here and there from single
Chair, DocBook Technical Committee | persons, rather than whole
                                   | nations, and from all nations,
                                   | rather than any one.--Sir Thomas
                                   | Browne