This is the mail archive of the docbook@lists.oasis-open.org mailing list for the DocBook project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


> 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>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]