[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: DOCBOOK: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC