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



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

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