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

[Eliot Kimber <ekimber@reallysi.com>]

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>