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'm happy with with Jeff's modifications to the language as I proposed it.

Jeff asks:

> 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?
  
In this context, what does "support" mean? I think the current language is a
bit underspecified, since I think that the processing referred to by the
current paragraph is about xref resolution and reflection, that is,
generating meaningful link anchors for xrefs.

However, the processing I've been focusing on for @type is simply validating
that the reference target matches the @type value. That processing is
completely orthogonal to xref or link processing.

I think it would be better to separate these two processing aspects so we
can make the conformance requirements clear. In particular, the current
statement about supporting type isn't really about @type validation but
about xref processing, and that language belongs in the defintion of <xref>,
not @type. Moving it there would make it clear that the conformance and
processing requirements there are a function of the type referenced, not the
validation of @type-defined constraints.

In the @type attribute itself, the question becomes "are conforming
processors required to validate @type at all?"

I think the answer is "yes". But since current behavior is that the
processing for ambiguous @type references is undefined, I think its
reasonable to say that, for DITA 1.2, processors are not required to support
qualified names in @type values and can either ignore them entirely or treat
them as unqualified names.

Cheers,

E.

On 7/7/09 3:00 PM, "Ogden, Jeff" <jogden@ptc.com> wrote:

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

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