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


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

<keydef keys="key-02"

<topicref id="key-01-use-01"

<topicref id="key-01-use-02"

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.



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

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:

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