[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-tc] discuss transclusion on Wednesday
Grosso, Paul wrote: > We need to explain somewhere that the definitions element > is removed as a result of the transclusion (if that, in fact, > is what we want--that's what the examples make it look like). You are right, although it doesn't matter whether definition is removed or now -- it's inside <info> element and it is not going to be rendered. > I still don't see where we explain what happens when a > transcluded region contains an info element with definitions, > especially in the case where we have profiling attributes > involved. This is still underspecified. I think that we agreed on not specifying those details before we know that we want to proceed with transclusion. > And having a transcluded region that contains an info element > with definitions will mean (I think) that the result of the > transclusion has some new definitions, but not the original > definitions (if we remove definitions as a result of the > transclusion as mentioned above). Hmmm, I think that if you transclude content with it's own definitions those definitions should remain valid and be used only for this transcluded content. > In Example 6, I don't see why os="linux" is chosen. > Perhaps we just need to say: > > Result of transclusion when os="linux" > > or something like that to make this clearer. Good catch, thanks. > Example 7 does not show the results of the transclusion. > (And when it does, it will have to say what value of os was used.) Yes, as this involves profiling I have postponed this. > In example 9, it wasn't clear to me whether ref's @definitionfile > was used as the only source of definitions I think this was intention > or if those in the > document's info element would also be available (and presumably > overridden by a definition of the same name in the definitionfile). My inclination is that if there is @definitionfile file on <ref> only definitions in this file are available. If you need to override this you can use only processor specific override mechanism. > We need to say what happens with a ref element has both a name > attribute and a fileref attribute. I think that this should be considered error. > I'd even be willing to give up on #auto. When the prefix is > auto-generated, we can avoid id clash, but one can't reference > into a transcluded region from outside. However, if you know > the prefix (because you specified in on the ref element), then > you will know what idref value to use to reference any id within > any transcluded region. So I don't see much added value--and > some downside--to having #auto. Probably this should be sufficient. Something similar was suggested also by Hussein Shafie another XML editor vendor: http://lists.oasis-open.org/archives/docbook/201012/msg00014.html Jirka -- ------------------------------------------------------------------ Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz ------------------------------------------------------------------ Professional XML consulting and training services DocBook customization, custom XSLT/XSL-FO document processing ------------------------------------------------------------------ OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member ------------------------------------------------------------------
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]