[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] DITA v1.2 Review | Propagating attribute values
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]