[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] DITA v1.2 Review | Propagating attribute values
I appreciate that this is a passionate subject, but please keep the
discussions based on facts and relative merits, keeping in mind that
we will almost certainly need to have a vote on a resolution next
week. I just have a feelin', ya know? Also, I trimmed the replies on this note to the one TC list because I'm getting 3 and 4 of these on each person's reply, and it makes inbox maintenance tedious. Since all on this particular discussion are TC members, would folks mind aiming to reply to the principle To: targets, whether dita-comments or the TC list? -- "Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?"
--T.S. Eliot
On 8/25/2010 1:19 PM, Eliot Kimber wrote: I feel pretty strongly where this is a case where the spec is wrong in one place and that the design intent was always clear. This is a case where the behavior has to be right even if clarifying it breaks existing implementations. The design intent was always that topicref behave like conref for the purpose of attribute merging. In the original proposal there are two conflicting statements, point 25 and point 26. How we missed that point 26 contradicts point 25 I don't know, but certainly Michael, Robert, and I are in agreement that point 25 is correct and point 26 is wrong and always has been. Cheers, E. On 8/25/10 1:01 PM, "Nitchie, Chris" <cnitchie@ptc.com> wrote:I think Paul's point on late-breaking changes to the spec applies here; this is exactly the opposite of what the spec currently says with respect to precedence. (And yes, our implementation for the next release, which reaches code complete this week and has been in development for a year, follows the current spec language.) From 2.1.3.4.3.3 Processing key references: ==== When attributes are combined, the attributes on a key definition element take precedence over the attributes on a key reference element. For a chain of key reference elements, the priority for combining attributes is: First key-defining element Second key-defining element ... last key-defining element key reference element ==== But aside from the impact of late-breaking spec changes to implementations, I feel pretty strongly that the proposed new behavior is undesirable. One of the main uses of keyref, as I understand it, is to allow map authors to repurpose content in new contexts. If the map cannot specify new attributes for key references, a lot of the power of that is blunted. For example, if an xref which is authored to point to a web url (@scope=external) needs to be reused in a context where the relevant target is instead part of the infoset (@scope=local), there's nothing the map author could do in the map to make this happen. If you want the effect described in the example below, I would think that @conref or @conkeyref would be the way to go. Chris -----Original Message----- From: Eliot Kimber [mailto:ekimber@reallysi.com] Sent: Wednesday, August 25, 2010 11:58 AM To: Tarun Garg; dita Subject: Re: [dita] DITA v1.2 Review | Propagating attribute values You have it backward--we have determined that the current language of the spec is incorrect. The intent is that key definitions behave *exactly* like conref, meaning that the referencing element's attributes override the referenced elements. For example, given this set of elements: <keydef keys="key-01" keyref="key-02" linking="targetonly"/> <keydef keys="key-02" href="topic-01.xml" linking="sourceonly"/> <topicref id="key-01-use-01" keyref="key-01" linking="none"/> <topicref id="key-01-use-02" keyref="key-01"/> Then for topicref "key-01-use-01" the effective value of @linking is "none", because it specifies that value directly. For toicref "key-01-use-02" the effective value of @linking "targetonly" because that's the value specified on the keydef for key "key-01". Also, whether an attribute is defaulted in a DTD or XSD or explicitly specified in an instance is entirely immaterial--to an XML processor the attribute is simply specified or not--how it came to be specified is unknowable and therefore cannot affect DITA processing. Cheers, Eliot On 8/25/10 3:24 AM, "Tarun Garg" <tarung@adobe.com> wrote:The attribute values get propagated: · For Keys from key-defining element to key-referencing element. · For Conref from referenced element to referencing element. An attribute value can be specified through two ways: · In the DTD; as the default/fixed value. · In the XML instance. So, while propagating the attribute values, I think the values specified in the XML instance itself shall only be considered for propagation. One of the reason I think so, is that the value specified in the DTD is already available in most cases and need not be propagated. Apart from this, the value specified in the XML instance, indicates the user intention to assign a specific value to an element & that needs to be propagated. One specific case for this relates to public review comment #C011 (http://lists.oasis-open.org/archives/dita-comment/201007/msg00016.html). For a <keydef> element the default value of @processing-role is define as ³resource-only² through the DTD. Now, there is a possibility that a user assigns value to @processing-role explicitly in the xml. These two cases are different and I think the propagation of the value shall happen differently for these two scenarios as follows. · If the value is defined through DTD It shall NOT be propagated from key-defining to key-referencing element. · If the value is explicitly specified in the XML - It shall be propagated from key-defining to key-referencing element. This is so because, in general for key-defining element, the @processing-role is controlled through DTD because, the purpose of the element is clear and per the standard. Now, if a user is specifying a value in the XML explicitly, then I assume the user wants some different behavior and hence, the value shall be propagated. Regards, Tarun Garg | Adobe Systems | +91-120-2444711 | tarung@adobe.com-- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]