Re: [dita] DITA v1.2 Review | Propagating attribute values

[Don Day <donday@learningbywrote.com>]

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

Don R. Day

DITA and XML Consultant

Chair, OASIS DITA Technical Committee

"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