[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: DOCBOOK: Re: Concrete proposal for #480954: Extend textobject toinsert external files
/ 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC