[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 suddenly find myself questioning everything I thought I knew about key references. Just so I'm clear, this means that if I have both @href and @keyref on an element, and the key definition also has an @href, the @href on the reference wins? Or is @href an exception? And if @href is an exception, then shouldn't @scope, @format, and @type be also? Say you had this xref: <xref keyref="website" scope="external" format="html" href="http://www.oasis-open.org";>website</xref> Is there no way to change where this xref points by defining 'website'? If that's the case, then the language in the spec about falling back to the href on the referencing element is probably irrelevant. The spec also states: ==== When a key definition has no @href value and no @keyref value, references to that key will not result in a link, even if they do contain an @href attribute of their own. ==== Is this a special case? It seems to run counter to the idea that the referencing element wins. I'm far from convinced that the spec shouldn't stand as-is. My objection isn't based on the fact that it'll force us to re-evaluate a lot of the keyref-related features we've been working on (though it will), but because if propagation works this way then keyrefs are a lot less useful than I thought they were. Chris -----Original Message----- From: Eliot Kimber [mailto:ekimber@reallysi.com] Sent: Wednesday, August 25, 2010 2:19 PM To: Nitchie, Chris; Tarun Garg; dita Subject: Re: [dita] DITA v1.2 Review | Propagating attribute values 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 > -- Eliot Kimber Senior Solutions Architect "Bringing Strategy, Content, and Technology Together" Main: 512.554.9368 www.reallysi.com www.rsuitecms.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]