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: Analysis of 1.3 Proposals Related to Linking and Addressing

The following proposals are concerned primarily or significantly with
linking and addressing.

Terminology note: 

By "linking" I mean establishing relationships among elements. <topicref>
and <xref> are examples of links in DITA.

By "addressing" I mean the syntax and semantics of pointers to things. URLs
and key references are examples of addresses.

Linking may use explicit pointers or implicit relationships (queries,
functions, heuristics). Addresses may be used for mechanical reasons that
are not linking in this sense, such as simply connecting two elements
together that serve as a single unit of data.

13001 -- Relative URLs for current topic
13002 -- More sophisticated linking into media objects
13004, 13005 -- Scoping of key definitions/references
13006 -- Override of references
13009 -- Indirection for element-to-element addresses
13022 -- Element-to-element relationship tables
13041 -- Allow specification of root scope for key references
13046 -- Allow @keyref in more places
13058 -- Reference a DITA topic in different contexts in the same map
13068 -- Say that if a topicref points to one topic in a file, a processor
may include only that one topic in output.
13069 -- Allow specifying a topic ID after a key name.
13072 -- Keyref to <mapref> element
13079 -- Update keyref definition to make distinctions between elements.

These proposals appear to reflect the following general requirements:

1. Addressing convenience: 13001, 13069

2. New addressing features: 13009, 13022

3. Clarify behavior of existing linking and addressing: 13068, 13072, 13079

4. New linking features (new types of relationship): 13002, 13022

5. Key-based addressing enhancements: 13004, 13005, 13041, 13046, 13006(?).

In particular, establishing the scope to which a given key definition or key
reference applies.

6. Scoping of "variables" by use context: 13068

I have put items (5) and (6) last because they are the big ones. Items 1-4
seem either relatively non-controversial or likely to be rejected for good
reasons (not useful, of too little value, etc.).

Items 5 and 6 will require significant architectural thought. I would
recommend establishing an ad-hoc workgroup to focus on the key-related

Item 6 is not necessarily about linking or addressing per-se--it's really
about scoping of "variables" and one way that has been expressed is through
the use of key references to define the content of elements (e.g.,
<keyword>, <term>). Key scoping may be one way to address that issue, but
it's not the only way and it is not possible for key-based approaches to
satisfy all the requirements that I've seen and as I understand them.

My considered opinion is that the key-scoping approach suggested by Jeremy
Griffith reflects an inappropriate attempt to use keys for something they
were not intended for. This is not to say that there aren't other legitimate
requirements and use for map-scoped keys, just that "variables" is not one
of them.

I think we need a new facility for variable scoping and that is what 13068
in particular is asking for. I have started working up some ideas but had
not yet taken the time to work up a full expression of my ideas. But I will
do so now that we are starting on 1.3 in earnest.



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]