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 wondering whether we should not give this change more thought before
throwing it into 1.2... The domain names are not usually exposed to the
users. We may wish to think through how this would impact users. Since
@class is not supposed to be in the source XML content (processors
insert it later when parsing against the DTD or schema), this change may
impact authoring in ways we have not considered. I'm hesitant to rush
this into 1.2 for these reasons. Does anyone else share my concerns, or
do y'all feel that because this is an edge case that only impacts
specializations that use official DITA element names, we don't need to
concern ourselves with such usability hits?

I plan to discuss this further at this week's meeting, but do encourage
list discussions prior to our meeting.

The way I see it, the change to the documentation is quick and easy, but
what impact will this have on 1) end users and 2) tools?

Cheers,
Gershon

-----Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com] 
Sent: Tuesday, June 30, 2009 7:23 PM
To: Ogden, Jeff; dita
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> 


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 



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