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: LW DITA Committee Note Draft: Use of Domains in LWDIta

I found it odd that domains were defined inconsistently: the highlight domain was modeled as a domain module but the media domain was defined inline in the DTDs.

It should be one or the other: either put all the declarations in one module or consistently break out the domains.

I think having everything in one module file makes sense for LW DITA *as long as* we also define the equivalent domains as conforming 1.3 modules.

This does several things:

1. Makes it clear that LW DITA is a conforming DITA 1.3 application
2. Makes it possible to use LW DITA markup in a normal DITA environment
3. Makes the same domains available in other contexts (one of Chris’ concerns, which I share).
I’m happy to volunteer to define (and maintain) the conforming versions of the constraints.

Also, the highlight domain as defined is not really a domain, it’s a constraint implemented through direct modification of the base domain files. We should avoid that.

If we accept that the LW DITA grammars (for each structural type) should be single files, then it makes sense to simply duplicate the original declarations and modify them, but the constraints still have to be named and reflected in the @domains attributes.

This is also consistent with a much more flexible notion of constraints that I certainly support and that I think we are working towards in DITA 2.0, namely that how you implement the constraints is much less important than the fact that you make it clear (via the @domains attribute) that constraints are in play.


Eliot Kimber

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