This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
Re: Re: Concrete proposal for #480954: Extend textobject toinsert external files
- To: docbook at lists dot oasis-open dot org, ndw at nwalsh dot com
- Subject: Re: DOCBOOK: Re: Concrete proposal for #480954: Extend textobject toinsert external files
- From: Bob Stayton <bobs at caldera dot com>
- Date: Mon, 12 Nov 2001 10:33:30 -0800 (PST)
- List-id: <docbook.lists.oasis-open.org>
> From: 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.
OK, thanks for the clarification. I think this
all makes sense.
> | 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. :-)
Ah, but such a useful marginal feature. 8^)
bobs
Bob Stayton 400 Encinal Street
Publications Architect Santa Cruz, CA 95060
Technical Publications voice: (831) 427-7796
Caldera International, Inc. fax: (831) 429-1887
email: bobs@caldera.com
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>