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: Two suggestions for the DITA 1.0 Specification


Based on the excellent discussion that took place over the past few days, it
seems that the DITA 1.0 Specification could benefit from two additional
topics:

A.  Which base classes in topic.mod are conceptually the best "abstract"
classes from which to specialize new elements of a given type?  For example,
given that we don't have an abstract class called <block element>, would
someone attempting to specialize a new block element be best advised to
specialize it from <p> or from something else?  Or for when you need a
titled block element, is <fig> the best choice?  Some short list to this
effect would be a boon to people approaching DITA for the first time.

B.  What are the ways in which you can more or less "safely" break DITA, and
what are the consequences.  Michael Priestley has talked about doing this in
one form or another, and I think the spec is as good a place as any.
Perhaps we could address basic techniques such as:

*  Making base class content models more restrictive in DTDs used for
authoring, but using unmodified DITA DTDs for output processing.

Benefit: Less complex doctypes for authors (by removing unnecessary choices)
and ability to make existing content models more specific if desired.  Your
DITA instances are still 100% valid and interchangeable with 3rd parties,
and assuming tools vendors do not validate CONREFed inclusions from 3rd
party sources that use unmodified DITA, you can also safely CONREF 3rd party
material into your more restrictive doctypes.

Issues: More complex maintenance of your DTDs/Schema because you have to
manage two sets:  a modified set for authors and an unmodified set for
output processing.



*  Adding new base classes or new base class attributes to your DTDs used
for both authoring and output processing.  The catch is that these added
elements or attributes must be *optional* in every context in which they
occur.

Benefit: Nearly complete flexibility for your modeling/application/CMS
needs.  You can still safely CONREF 3rd party instances created with
unmodified DITA into your doctypes, even if tools vendors actually validate
CONREFed inclusions.  You can still make use of DITA transforms in the
public package and publically developed DITA transforms, requiring that you
code only incremental specializations to transforms to deal with your new
base elements/attributes.

Issues: Your DITA instances will *not* valid DITA and will therefore will be
unusable by 3rd parties.  Interchange is one-way only, unless you create
special transforms specifically for interchange processing that: strip your
special attributes from instances,  convert your added tags to some roughly
equivalent tag in base DITA, and modify your DTDs/Schema handed out for
interchange to specify different class paths for any elements that were
specialized from your added base classes.  It's nasty but it could be done.

------

There may be other ways to "safely" break DITA, but those are the two main
ways that came to mind.  For the folks that are hesitant to adopt DITA
because they feel it doesn't meet their specific modeling requirements, I
think a frank discussion of these "safe" practices in the 1.0 spec itself
can go a long way towards helping them feel better about adopting DITA
earlier rather than later.

To that end, it might be also useful to discuss, in the same topic, the ways
in which future releases of DITA might evolve to remove the need to perform
these types of "safe" breakages.  For example, we already know that we have
to devise a mechanism to allow for specialization of attributes.  We've also
discussed the desirability of eventually adding new, more abstract base
classes in order to help purists feel better about being able to create the
models they need (ref: Eliot Kimber's strong aversion to specialing <fig>
for an element that is not semantically a graphic of some sort).

Can we stave off objections to limitations in the 1.0 release by including
these two topics in the spec?


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