This is the mail archive of the
docbook@lists.oasis-open.org
mailing list for the DocBook project.
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: Concrete proposal for #480954: Extend textobject toinsert external files
- From: Bob Stayton <bobs at caldera dot com>
- Date: Mon, 12 Nov 2001 09:33:45 -0800 (PST)
- List-id: <docbook.lists.oasis-open.org>
> From: Norman Walsh <ndw@nwalsh.com>
>
> The content model of inlinemediaobject is currently:
>
> inlinemediaobject ::=
> (objectinfo?,
> (videoobject|audioobject|imageobject),
> (videoobject|audioobject|imageobject|textobject)*)
>
> And the stylesheets support a hack whereby you can say
>
> <imageobject format="linespecific" fileref="somefile.txt"/>
>
> and literally insert the content of somefile.txt into the result.
>
> As this RFE suggests, it might be more reasonable to allow textobject
> to directly insert a file by adding entityref and fileref attributes
> to textobject.
>
> 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)*))
>
> In other words, you would be able to have an inlinemediaobject with
> one or more textobjects or one with a "proper" mediaobject and
> alternatives, but you wouldn't be allowed to have a textobject and an
> imageobject but put the textobject first. I think that preserves the
> existing semantics.
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).
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.
These seem like two very different animals, and could
lead to some confusion in how they are used, no?
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 agree we need something other than the hack, but I
want the semantics to be unambiguous.
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>