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