[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 If the type attribute is
specified when referencing a DITA
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]