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


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


-----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,
> 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
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
1.2. Essentially, @scope only makes sense in the context of direct
references to resources because the initial reference to a resource
(and should not) know whether the ultimate target is part of the
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
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
a topic or non-DITA object at all, since it could be just text fetched
a keydef not bound to a resource at all.

The best a processor could do is compare the specified scope value on
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
point in specifying scope on a keyref because it cannot change the way
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,
definition, made in the map tree that contains the key reference),
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
in a peer or external key space (separate map tree).

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



Eliot Kimber
Senior Solutions Architect
"Bringing Strategy, Content, and Technology Together"
Main: 512.554.9368

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