RE: [dita] DITA v1.2 Review | Propagating attribute values

["Nitchie, Chris" <cnitchie@ptc.com>]

Eliot,

I agree that this is nonsensical:

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

But this is not:

<xref keyref="key-01" href="http://www.example.com"; scope="external"/>

What you don't say explicitly, but what I take you to mean, is that in
this case, the scope on the xref only applies if no definition exists
for key-01, that is, only when the xref's href applies. At least, that's
my interpretation (and why I said scope, format, and type are treated
the same as href).

Chris

-----Original Message-----
From: Eliot Kimber [mailto:ekimber@reallysi.com] 
Sent: Thursday, August 26, 2010 1:04 PM
To: Nitchie, Chris; dita
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