OASIS Darwin Information Typing Architecture (DITA) TC

In the Language Reference, within the topic "The type attribute", under the
title "Using type on a linking element", append the following to the third
paragraph ("If the type attribute is specified..."):



Cheers,

Eliot


----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email:  ekimber@reallysi.com 

Is this a good idea?  It seem like a big change from the type values
that were called for in DITA 1.0 and 1.1 (topic, concept, fig, fn, ...).
Is this in support of a DITA 1.2 proposal?  Was it something that the
DITA TC talked about and agreed to?  Please point me at an e-mail
discussion or other document if I missed something.

   -Jeff

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com]
> Sent: Tuesday, June 30, 2009 10:05 AM
> To: dita
> Subject: [dita] ITEM: Meaningful Values for type= on xref and topicref
> 
> In the Language Reference, within the topic "The type attribute",
under
> the
> title "Using type on a linking element", append the following to the
> third
> paragraph ("If the type attribute is specified..."):
> 
> 
> 
> Cheers,
> 
> Eliot
> 
> 
> ----
> Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
> email:  ekimber@reallysi.com 

On 6/30/09 10:08 AM, "Ogden, Jeff" 

I think this is a much bigger deal than a "bug fix".  It is an
incompatible change from DITA 1.0 and 1.1. Those versions of the spec.
told people to use "fig", "fn" and similar element name values.  I guess
this isn't as bad as it might be because you use the word "SHOULD"
rather than the word "MUST" or "REQUIRED".  Still it will make old
documents incorrect with respect to the DITA 1.2 spec. and it will
require processors that were working OK with DITA 1.0 and DITA 1.1 to be
changed.  So I don't think this is a good idea.

And, is having different styles @type values for topic references and
sub-topic references a good thing?  Or will users find that confusing?

But if we are going to make this change or move in this direction,
shouldn't we at least document both the old and new values and say that
processors SHOULD implement both to allow a transition to the new style?
And what is the correct syntax to get a footnote with the new scheme?
Other parts of the spec. still call for the use of type="fn", don't
they?

   -Jeff

> 

                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
> From: Eliot Kimber [mailto:ekimber@reallysi.com]
> Sent: Tuesday, June 30, 2009 11:15 AM
> To: Ogden, Jeff; dita
> Subject: Re: [dita] ITEM: Meaningful Values for type= on xref and
> topicref
> 
> On 6/30/09 10:08 AM, "Ogden, Jeff" 

My proposed language explicitly says that references to standard-defined
element types do not need to be qualified, so the existing practice is
allowed and should work (because standard-defined local names are, by
necessity, globally unique across all standard-defined vocabulary modules).

But I do agree that this would affect the code in processors that checks
type values, in that it would now have to check both the local name and the
class value of the target. However, it's difficult to imagine that this is
an onerous burden since you'd expect there to be one function in a given
processor that checks @type values and it's a few lines of code to add the
check of @class values.

The problem with *not* doing this is that when users *know* that a
particular reference is ambiguous (because they know they have topics that
integrate different modules with duplicate local names) and they really want
the processor to fail when you point to foo-d/bar when you should have
pointed to fred-d/bar, then users will be unable to get that behavior.

But I also agree that in practice the the case is probably not that common.

In hindsight it's clear at least to me that, having defined a qualified
naming mechanism for element types, that the DITA standard didn't always
allow qualified names wherever type references occur.

Cheers,

E.

On 6/30/09 11:10 AM, "Ogden, Jeff" 

I'm wondering whether we should not give this change more thought before
throwing it into 1.2... The domain names are not usually exposed to the
users. We may wish to think through how this would impact users. Since
@class is not supposed to be in the source XML content (processors
insert it later when parsing against the DTD or schema), this change may
impact authoring in ways we have not considered. I'm hesitant to rush
this into 1.2 for these reasons. Does anyone else share my concerns, or
do y'all feel that because this is an edge case that only impacts
specializations that use official DITA element names, we don't need to
concern ourselves with such usability hits?

I plan to discuss this further at this week's meeting, but do encourage
list discussions prior to our meeting.

The way I see it, the change to the documentation is quick and easy, but
what impact will this have on 1) end users and 2) tools?

Cheers,
Gershon



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com] 
Sent: Tuesday, June 30, 2009 7:23 PM
To: Ogden, Jeff; dita
Subject: Re: [dita] ITEM: Meaningful Values for type= on xref and
topicref 

My proposed language explicitly says that references to standard-defined
element types do not need to be qualified, so the existing practice is
allowed and should work (because standard-defined local names are, by
necessity, globally unique across all standard-defined vocabulary
modules).

But I do agree that this would affect the code in processors that checks
type values, in that it would now have to check both the local name and
the class value of the target. However, it's difficult to imagine that
this is an onerous burden since you'd expect there to be one function in
a given processor that checks @type values and it's a few lines of code
to add the check of @class values.

The problem with *not* doing this is that when users *know* that a
particular reference is ambiguous (because they know they have topics
that integrate different modules with duplicate local names) and they
really want the processor to fail when you point to foo-d/bar when you
should have pointed to fred-d/bar, then users will be unable to get that
behavior.

But I also agree that in practice the the case is probably not that
common.

In hindsight it's clear at least to me that, having defined a qualified
naming mechanism for element types, that the DITA standard didn't always
allow qualified names wherever type references occur.

Cheers,

E.

On 6/30/09 11:10 AM, "Ogden, Jeff" 

On 7/5/09 6:40 AM, "Gershon Joseph (gerjosep)"