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] ITEM: Meaningful Values for type= on xref and topicref


I went back and looked at Eliot’s original e-mail on this and found the note from 10:05 AM on June 30th (included below).

 

If I apply your suggested change to the draft Language Reference, I get the following (the addition is underlined and in blue):

 

If the type attribute is specified when referencing DITA content, it should match one of the values in the target's class attribute. For example, if type="topic", the link could be to a generic topic, or any specialization of topic, including concept, task, and reference. Applications may, but need not, issue a warning when the specified or inherited type attribute value does not match the target (or a specialization ancestor of the target). When referencing elements within topics, the value of the type attribute should specify the fully-qualified class value for the target element, e.g. "my-list-d/my-li-type". For element classes defined by standard DITA vocabulary modules, the module name and separator may be omitted (e.g. "li" rather than "topic/li").

 

And that just doesn’t sound like it is “allowing, but not requiring qualification” to me.

 

I’d be OK with rewording this to read something like this (changes underlined/bold/orange and deletions in red strikethrough):

 

If the type attribute is specified when referencing a DITA contenttopic or map, it shouldMUST match one of the values in the target's class attribute. For example, if type="topic", the link could be to a generic topic, or any specialization of topic, including concept, task, and reference. Applications may, but need not, issue a warning when the specified or inherited type attribute value does not match the target (or a specialization ancestor of the target). When referencing elements within DITA topics or maps, the value of the type attribute shouldMUST specify the fully-qualified class value for the target element, e.g. "my-list-d/my-li-type" or an unqualified element name from the target’s class attribute. For element classes defined by standard DITA vocabulary modules, the module name and separator may be omitted (e.g. "li" rather than "topic/li").

 

If we go down this path, I’d think we’d also need to change this from the last paragraph in the same section:

 

Processing is only required to support the above list or specializations of types in that list. Supporting additional types as targets may require the creation of processing overrides.

 

Since the current list consists of unqualified element names (fig, table, li, fn, …). Do we want/need to require processors to support the qualified names for items on this list or should we add the qualified names to the list so that processors are required to support both?  Are we comfortable putting new requirements on processors at this late stage of DITA 1.2?

 

While I’d be OK with the above, because we are so far along in the DITA 1.2 cycle I’d also be OK with putting this off until DITA 1.3.

 

    -Jeff

 

> -----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..."):

>

> <ph rev="1.2">

> When referencing elements within topics, the value of the type attribute

> should specify the fully-qualified class value for the target element, e.g.

> "my-list-d/my-li-type". For element classes defined by standard DITA

> vocabulary modules, the module name and separator may be omitted (e.g. "li"

> rather than "topic/li").

> </ph>

>

> Cheers,

>

> Eliot

 

------------------

 

> -----Original Message-----

> From: Eliot Kimber [mailto:ekimber@reallysi.com]

> Sent: Tuesday, July 07, 2009 1:04 PM

> To: Ogden, Jeff; Gershon Joseph (gerjosep); dita

> Subject: Re: [dita] ITEM: Meaningful Values for type= on xref and

> topicref

>

> On 7/7/09 10:20 AM, "Ogden, Jeff" <jogden@ptc.com> wrote:

>

> > OK, what if a user has set @type="myfig" where myfig is a

> specialization

> > of fig? That is what the DITA 1.0 and DITA 1.1 specs call for.

> Doesn't

> > that become invalid with your proposal?

>

> This is the case that is currently broken: this reference cannot be

> unambiguously checked in all cases. The intent of my proposal is to

> *allow*

> qualification in this case, not require it. Any requirement is

> functional,

> as in "if you want to be sure the type can be checked, it must be

> qualified".

>

> > And what about specialized elements that are part of a DITA TC

> defined

> > specialization (task, concept, hazardstatement, ...), but not part of

> > the base topic or map definitions?  How are those different from user

> > defined specializations in terms of uniqueness?

>

> Because the TC provides shells that integrate all the modules (e.g.,

> ditabase) and because there is always the possibility that somebody

> might

> want to integrate any two TC-supplied domains or topic types into a

> local

> shell or specialization, the TC must ensure that all local names for

> TC-provided modules are unique in that scope.

>

> By the same token, any module implementor who has any expectation that

> their

> module might be used outside the scope of their local architectural

> control

> (e.g., their content might be interchanged outside their local sphere

> of

> control), they also have an obligation to ensure that their local names

> don't duplicate any local names in standard vocabularies (and by

> implication, any other well-known vocabularies that are likely to be

> integrated with their modules). This is a practical constraint, not a

> formal

> constraint by the spec.

>

> However, beyond these two scopes (TC-defined and locally defined and

> managed) there's no point in trying to worry about local name

> uniqueness

> because it's simply unknowable.

>

> I don't want to push this issue too hard: it's clearly not a deal

> breaker.

> My thinking was it seemed like a pretty easy fix to bug but if there's

> consensus that it's too disruptive a change for 1.2 let's carry it over

> to

> 1.3.

>

> I say lets put to an up or down vote at the next TC meeting.

>

> Cheers,

>

> Eliot

>

> ----

> Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.

> email:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>

> office: 610.631.6770 | cell: 512.554.9368

> 2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403

> www.reallysi.com <http://www.reallysi.com>  | http://blog.reallysi.com

> <http://blog.reallysi.com> | www.rsuitecms.com

> <http://www.rsuitecms.com>

 



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