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: my opinion of some DITA 1.2 proposals


The TC seems to be in the habit of generally accepting
a proposal once discussion on it has seemed to die down.
We don't seem to have much of a precedence for turning
down a proposed feature, and we don't seem to have had
much TC discussion on the complexity of the DITA 1.2
release as a whole.

I realize that different TC members will reasonably
have different customer bases and different use cases
in mind.  I further realize that all the suggested
proposals have some merit in some cases, and I certainly
don't question the usefulness of each proposal to its
proposer.  

But I am concerned about the overall complexity of DITA 
in general and in a point release such as 1.2 especially.
Therefore, there are several 1.2 proposals that I do not
feel are warranted doing in 1.2 and that I plan to suggest 
that we drop from 1.2.  Rather than wait to the last minute
to express my opinion, I prefer to state my thoughts up
front at this time.

The following three are complicated, esoteric, and, in
my opinion, have more cost then benefit in terms of 
complicating the specification itself, the task of
learning about DITA, and the ongoing use of DITA, to
say nothing of the implementation:

12008 Constraints - restriction without specialization
12010 Domain and topic integration
12031 Controlled values / taxonomies

Regarding:

12013 Referencing a range of elements

I can see how it might be nice for some users, but I've 
been burnt too much by problems with XPointer ranges (this
is one of the key reasons that the W3C XPointer scheme was
turned down as a W3C Recommendation and dropped as a W3C
work item), and there are just too many issues and edge 
conditions that would need to be resolved.  Furthermore, 
I'm not convinced it's a good thing to be able to give a 
start and end of a conref reference where what's actually
referenced (between the two points) could change from moment 
to moment.  While I can understand the desire, I don't think 
it's really a good thing, and I don't think the benefits 
outweigh the costs of addressing all the possible cases, 
most of which are error conditions.

Other proposals where I'm still undecided but which are 
not yet well defined and/or border on the too complex in 
my view are:

12015 Conref push instead of pull
12016 Semantic (implicit) linking
12020 Allow easy reuse of small pieces of text 
	(I have not yet read Deborah's latest on 12020)

paul


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