OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-tc message

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



  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

OpenPGP digital signature

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]