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