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


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" <jogden@ptc.com> wrote:

> 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-----
>> 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" <jogden@ptc.com> wrote:
>> 
>>> 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.
>> 
>> http://lists.oasis-open.org/archives/dita/200905/msg00033.html
>> 
>> 
>> This is essentially a bug fix: DITA has always been broken in this
>> regard in
>> that xrefs to specialized types where the name is not qualified are
>> potentially ambiguous as there's no requirement that a given non-topic
>> element name be globally unique across all possible vocabulary
> modules.
>> 
>> For example, if you xref to another topic and say type "foo", it's
>> ambiguous
>> whether you mean "my-domain-d/foo" or "your-domain-d/foo".
>> 
>> Cheers,
>> 
>> E.
>> ----
>> 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]