Re: [dita] 1.2 Requirements Ranking

[Erik Hennum <ehennum@us.ibm.com>]

Hi, Eliot:

Good to have this thoughtful review of the full list. A specific follow up on issue 12008:

- 12008 - Potentially very complicated, not clear that it's needed, could be controversial

The proposal (http://www.oasis-open.org/committees/download.php/14936/Issue34.html) cites some posts on the user group and TC mailing lists that provide background but doesn't itself provide an adequate explanation of the two most common scenarios. So, here goes:

Scenario 1: Some adopters want to simplify content models without adding new semantics.

For example, to exclude phrase elements and text (allowing only block elements) from <section> and specializations with a content model where that constraint could also apply (such as <context> and <prereq>). In particular, Paul Prescod surfaced that issue to the TC early on.

Scenario 2: Some adopters want to provide specialized domain elements as an alternative or replacement to the base element in specific content models.

For example, the style policies stuff that John Hunt and I are cultivating needs to add <blockLayout> as an alternative to <data> within <p> and its specializations, <linkLayout> as an alternative to <data> within <xref> and its specializations, and so on. If <blockLayout> and <linkLayout> are available in all <data> contexts (so that, for instance, <linkLayout> is available within <p>), the document type becomes unusable.

If the full constraints proposal seems too much for DITA 1.2, one possibility would be to support contextual domains only as a partial step down that path so at least the second scenario can be supported.

One additional case for trying to make progress on contextual domains: the control of the document type shell over the nesting of topics resembles contextual domains, so it might be plausible to recognize both with a single mechanism introduced as part of topic-domain unification. Such a mechanism could, for instance, allow runtime detection of incompatibilities between shell documents that use the same topics but impose different topic nesting.


Hoping that clarifies,


Erik Hennum
ehennum@us.ibm.com

"W. Eliot Kimber" <ekimber@innodata-isogen.com>

"W. Eliot Kimber" <ekimber@innodata-isogen.com>

03/20/2007 08:51 AM

To	"DITA TC list" <dita@lists.oasis-open.org>
cc
Subject	[dita] 1.2 Requirements Ranking

Top 5 critical:

12011 - I think the current task model is too specialized, precluding
many useful other specializations of task.

12016 - This is a key functionality that would help make the use of DITA
much easier and more natural

12047 - Maps are a key distinguisher for DITA and this proposal provides
needed and natural refinements

12007 - Need an indirection mechanism of some sort. Also need a "logical
name reference" mechanism. Keyref may or may not be one or the other of
these but it stands as a placeholder for the requirements.

12010 - This seems like an important refinement to the specialization
mechanism that needs to be done sooner rather than later.


Simple:

12001 - Implies no functional change to spec
12009 - Seems obvious and easy
12018 - Needed bug fix
12019 - Another non-controversial proposal
12022 - Obvious bug fix
12023 - Ditto
12024 - Easy
12028 - No functional change
12029 - Easy to implement, no functional change to existing docs
12035 - Requires a little design but should be non-controversial
12043 - Easy
12046 - Easy
12051 - Should be there already
12052 - Ditto

Issue that I didn't choose and why:

- 12008 - Potentially very complicated, not clear that it's needed,
could be controversial
- 12013 - Workaround exists to satisfy requirement
- 12015 - Potentially complicated, at least in terms of clearly defining
processing implications.
- 12020 - Can do this today with local specializations or just using
<ph> element. Not required to meet stated requirements
- 12021 - I am now in agreement with Michael that section should not nest
- 12026 - Is there more that needs doing for glossary?
- 12030 - Namespace issues should be deferred to 2.0
- 12031 - Complex issue
- 12033 - Potentially complex issue. Could effect other aspects of
specialization
- 12039-41 - Can be satisfied by vertical-specific specialization
package. Does not need to be in core DITA spec.
- 12044 - Not clear what the value of this is if attribute has useful
default.
- 12053 - Potentially complex or controversial feature

Everything else just fell between most important or easy but I have no
particular objection to or enthusiasm for it.

Cheers,

Eliot
--
W. Eliot Kimber
Professional Services
Innodata Isogen
8500 N. Mopac, Suite 402
Austin, TX 78759
(214) 954-5198

ekimber@innodata-isogen.com
www.innodata-isogen.com