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] DITA v1.2 Review | Propagating attribute values


On 8/26/10 11:44 AM, "Nitchie, Chris" <cnitchie@ptc.com> wrote:

> Eliot,
> 
> Thanks very much for the explanation. That makes a lot of sense, and
> more or less matches my understanding. I still think scope, format, and
> type should be treated the same as href since they're so tightly
> interrelated, but otherwise I feel much better now.

@scope, @format, and @type are addressing attributes in that they serve to
characterize the target resource (@format, @type) or characterize the
address itself (@scope). So again it would not be sensible to have those
attributes propagate from reference to referenced.

@scope is a bit problematic because its semantic is underspecified in DITA
1.2. Essentially, @scope only makes sense in the context of direct
references to resources because the initial reference to a resource cannot
(and should not) know whether the ultimate target is part of the reference's
using map tree or not.

That is, given this xref:

<xref keyref="key-01" scope="external"/>

The @scope value is patent nonsense because the author has no way of knowing
whether or not the resource ultimately addressed by the referenced key is or
is not part of the map containing the <xref>, or if in fact the resource is
a topic or non-DITA object at all, since it could be just text fetched from
a keydef not bound to a resource at all.

The best a processor could do is compare the specified scope value on the
reference with the ultimate scope value on the direct reference to the
resource and give a warning if they don't match, but otherwise there's no
point in specifying scope on a keyref because it cannot change the way the
ultimately-addressed resource affects processing.

Because DITA 1.2 has no way to explicitly establish the key-definition
context of a given key reference (in DITA 1.2 all key definitions are, by
definition, made in the map tree that contains the key reference), there's
no useful sense in which a key reference can have a scope other than
"local", since there's no way to indicate you are referencing a key defined
in a peer or external key space (separate map tree).

A key *definition* that specifies @href may usefully indicate @scope since
it knows what the relationship of a directly-referenced resource is relative
to its own containing map tree. But no reference to that key can possibly
know, for sure, what that relationship is.

Cheers,

Eliot 




-- 
Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368
www.reallysi.com
www.rsuitecms.com



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