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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

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


Subject: RE: [dita] Clarification of conref and cascading attributes


Agreed

I would think that when

<topicref id="sample"/>

or any other fragment for that matter, is the target of a conref it is taken
out of its context without its context and put into another context.

> -----Original Message-----
> From: dita@lists.oasis-open.org [mailto:dita@lists.oasis-open.org] On
Behalf
> Of Robert D Anderson
> Sent: September-06-12 12:55 PM
> To: dita
> Subject: [dita] Clarification of conref and cascading attributes
> 
> 
> I'm trying to clarify the proper way to evaluate a conref when the target
of a
> conref may be subject to inherited attributes. Relevant specification
sections
> are the topic on how attributes cascade in a map [1] (specifically the
section
> Rules for cascading in the map), and the topic on conref [2].
> 
> Question 1:
> Assume I have this map (showing only relevant attributes):
> <map>
>   <topicref conref="#sample"/>
>   <topicref audience="all" translate="no" linking="none">
>     <topicref id="sample"/>
>   </topicref>
>   <topicref conref="#sample"/>
> </map>
> 
> Based on [1], @conref must be evaluated before attributes are inherited.
> So, I believe that the resolved conref will not pull in the @audience /
> @translate / @linking values, because conref is evaluated before we try to
> inherit any attributes. The conref rules on pulling attributes from a
target
> ([2]) also refer only to "specified" attributes (not cascaded), with an
> exception carved out for @xml:lang.
> 
> Question 2:
> The conref at the end must be evaluated the same way, correct? Because if
> we went strictly in document order, you could say that the first one is
> evaluated, then id="sample" is evaluated (attributes cascaded), then the
last
> is evaluated based on the fully-resolved target. I think any solution that
> gives different results for the 2 conref's is illogical / wrong / evil
> -- just wanted to clarify that whatever the results, they will match.
> 
> Question 3:
> The specification really only talks about cascading in maps, but I believe
the
> same rules should apply in topics. That is, we should not have one rule
for
> how @audience cascades in maps, and a different rule for how it cascades
in
> topics. Specifically, this means the attribute cascade should work the
same in
> the first sample as in the following sample.
> <p conref="#topic/p"/>
> <section audience="all" translate="no">
>   <p id="p">sample</p>
> </section>
> <p conref="#topic/p"/>
> 
> Thanks -
> 
> [1]
> http://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/cascading-in-a-
> ditamap.html
> [2] http://docs.oasis-open.org/dita/v1.2/os/spec/archSpec/conref.html
> 
> Robert D Anderson
> IBM Authoring Tools Development
> Chief Architect, DITA Open Toolkit (http://dita-ot.sourceforge.net/)
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dita-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: dita-help@lists.oasis-open.org



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