OASIS Darwin Information Typing Architecture (DITA) TC

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

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:

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

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" 

  
    
    
  
  
    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:
    
25ekimber@reallysi.com" type="cite">
      
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
                                                
                                                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


      
      

    


  

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:



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

I'm confused. I may be completely misunderstanding what you're saying,
Chris, but here's my understanding.

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

In my simple brain I thought that "the @href on the referencing element"
that also has a @keyref is _always_ irrelevant unless the definition of
the key name fails to resolve to a resource. It's a fallback. That's
what "the language in the spec about falling back to the href on the
referencing element" means. It's at 2.1.3.4.3.2 "Using keys to address
DITA elements":

        If both @keyref and @href attributes are specified 
        on an element, the @href value must be used as a 
        fall-back address when the key name is undefined, 
        and should be used as a fall-back address when the 
        key name is defined but the key reference cannot 
        be resolved to a resource.

I'm not sure where the generalization "the reference wins" comes from.
Several references are in play here. The @href on the referring element
'wins' only if the reference specified in the key definition fails.

In your example above, the key name "website" is set to the @href
reference given in the effective 

Bruce has it right: if an element specifies both @keyref and @href and the
key reference can be resolved to a resource, then the @href is ignored.

Cheers,

E.

On 8/26/10 10:20 AM, "Bruce Nevin (bnevin)" 

Bruce,

Your understanding matches mine exactly (which is no small relief).  But
Eliot's message
(http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/201008
/msg00109.html), which I may well not understand correctly, seemd to
state that propagation should work the other way. That is, if an
attribute is specified on both a key reference and the matching
effective key definition, then the value on the key reference should be
the effective value for processing, and the value on the key definition
does not apply.

Eliot, I see from the archive (I haven't gotten the message in my inbox
yet) that you concurs with Bruce, which is an even bigger relief, but
I'm not sure how to square that with your earlier message.

Chris



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Bruce Nevin (bnevin) [mailto:bnevin@cisco.com] 
Sent: Thursday, August 26, 2010 11:20 AM
To: dita
Subject: RE: [dita] DITA v1.2 Review | Propagating attribute values


I'm confused. I may be completely misunderstanding what you're saying,
Chris, but here's my understanding.

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

In my simple brain I thought that "the @href on the referencing element"
that also has a @keyref is _always_ irrelevant unless the definition of
the key name fails to resolve to a resource. It's a fallback. That's
what "the language in the spec about falling back to the href on the
referencing element" means. It's at 2.1.3.4.3.2 "Using keys to address
DITA elements":

        If both @keyref and @href attributes are specified 
        on an element, the @href value must be used as a 
        fall-back address when the key name is undefined, 
        and should be used as a fall-back address when the 
        key name is defined but the key reference cannot 
        be resolved to a resource.

I'm not sure where the generalization "the reference wins" comes from.
Several references are in play here. The @href on the referring element
'wins' only if the reference specified in the key definition fails.

In your example above, the key name "website" is set to the @href
reference given in the effective 

The addressing attributes themselves do not propagate.

I think there may be some confusion around the addressing
attributes--attributes involved in defining addresses and characterizing
resources addressed cannot propagate in any sense--they simply establish one
step in a potentially multi-step chain of addresses.

Thus there is no sense in which a later key definition's addressing
properties *override* the properties specified on an earlier key
definition's addressing properties. Rather, the properties on two stages in
a multi-stage address are simply effective *on that stage* or they are not.

In particular, for keydefs that specify both @href and @keyref, there is no
sense in which the @href attributes of later stages "override" @href
attributes of earlier stages. Rather the basic rule of @keyref precedence
applies: if any keydef's keyref can be resolved then it's @href is ignored.

For example, consider this set of key definitions:

Eliot,

Thanks very much for the explanation. That makes a lot of sense, and
more or less matches my understanding. I still think scope, format, and
type should be treated the same as href since they're so tightly
interrelated, but otherwise I feel much better now.

Thanks,

Chris



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com] 
Sent: Thursday, August 26, 2010 12:35 PM
To: Nitchie, Chris; dita
Subject: Re: [dita] DITA v1.2 Review | Propagating attribute values

The addressing attributes themselves do not propagate.

I think there may be some confusion around the addressing
attributes--attributes involved in defining addresses and characterizing
resources addressed cannot propagate in any sense--they simply establish
one
step in a potentially multi-step chain of addresses.

Thus there is no sense in which a later key definition's addressing
properties *override* the properties specified on an earlier key
definition's addressing properties. Rather, the properties on two stages
in
a multi-stage address are simply effective *on that stage* or they are
not.

In particular, for keydefs that specify both @href and @keyref, there is
no
sense in which the @href attributes of later stages "override" @href
attributes of earlier stages. Rather the basic rule of @keyref
precedence
applies: if any keydef's keyref can be resolved then it's @href is
ignored.

For example, consider this set of key definitions:

On 8/26/10 11:44 AM, "Nitchie, Chris" 

Eliot,

I agree that this is nonsensical:

Exactly. 

Cheers,

E.

On 8/26/10 12:42 PM, "Nitchie, Chris" 

Aside from the problems I have redefining how something basic like
propagation works at this late stage, I'd point out that treating attribute
values determined by explicit specification versus by DTD default as different
is something that should be done very carefully.  



For example, in SGML days, the (ESIS) data model made no
distinction.  It was a conscious decision that there would be no way to
distinguish between an attribute value that was determined by being defaulted
in the DTD versus one that had an explicit assignment, and the XPointer/XSLT
data model also does not allow for any such distinction.



I would be very loath--especially at this point--to say that
propagation differs depending on whether an attribute's value was explicitly
specified versus defaulted in the DTD.



paul









From: Tarun Garg
[mailto:tarung@adobe.com]

Sent: Wednesday, 2010 August 25 3:25

To: dita@lists.oasis-open.org

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







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

Tarun,

I think we've resolved the issue of attribute propagation by key definitions
but I don't think we ever responded to the details of this specific note.

Namely, whether or not an attribute is specified in a document instance or
is defaulted in a DTD or schema can have no effect on processing because
after parsing the two cases are indistinguishable, meaning a processor
either cannot know how the attribute value came to be (because the parser
simply reports the attribute value, not how it was specified) or the
processor can know (e.g., an XML editor) but must ignore that knowledge.

Thus it would not be possible for the DITA standard to define behaviors
based on whether or not a given attribute was defined as a DTD- or
schema-provided default.

Or said another way, all DITA processing must work for documents that have
no associated DTD or XSD (or other form of document constraint
specification) meaning that for such documents all attributes are either
specified or not specified in the instance, because that's all you have.

Cheers,

Eliot

On 8/25/10 3:24 AM, "Tarun Garg" 

Hi Eliot,

I am still unclear that whether such a behavior cannot be defined because of the processor not being able to distinguish between such values or some other reason.

In case, it is due to the processor, than I would say that is a implementation-level thing that a processor can take care of. Also, as you mentioned there are some that are able to do so now as well. Also, sometimes the need causes the implementations to happen :).  So if we define such a behavior, may be such implementations become common.

Regards,
Tarun Garg | Adobe Systems | +91-120-2444711 | tarung@adobe.com



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com] 
Sent: Wednesday, September 22, 2010 4:36 PM
To: Tarun Garg; dita
Subject: Re: [dita] DITA v1.2 Review | Propagating attribute values

Tarun,

I think we've resolved the issue of attribute propagation by key definitions
but I don't think we ever responded to the details of this specific note.

Namely, whether or not an attribute is specified in a document instance or
is defaulted in a DTD or schema can have no effect on processing because
after parsing the two cases are indistinguishable, meaning a processor
either cannot know how the attribute value came to be (because the parser
simply reports the attribute value, not how it was specified) or the
processor can know (e.g., an XML editor) but must ignore that knowledge.

Thus it would not be possible for the DITA standard to define behaviors
based on whether or not a given attribute was defined as a DTD- or
schema-provided default.

Or said another way, all DITA processing must work for documents that have
no associated DTD or XSD (or other form of document constraint
specification) meaning that for such documents all attributes are either
specified or not specified in the instance, because that's all you have.

Cheers,

Eliot

On 8/25/10 3:24 AM, "Tarun Garg"