So it’s essentially just documentation that might be of value to an observer.

 

I guess one of my concerns is that there would be an expectation that, for example, editors would enforce the constraints regardless of the actual DTD or schema declarations. If that’s not really the intent then I have less objection to the proposal, although I’m not sure I fully recognize it’s practical value. But it still seems like an awful lot of specification development effort for very little practical day-to-day benefit to DITA users.

 

From a practical standpoint the presence or absence of these declarations is not really going to matter to most people most of the time—they’ll author their content according to whatever DTD they are using and will publish it with the Toolkit or whatever and as long as that works they’ll be fine.  I will point to the domains= attribute as a good example: the only time it had an effect was when it *wasn’t* specified and that was only because the Toolkit code was badly written and assumed it would be there, even though the value is not used for anything as far as I could tell from the code. How will this be different?

 

I must also admit that I have yet to really agree with the necessity or advisability of the architectural constraints that are purported to “enable” interoperation—it still seems to me that as long as two topics conform to the constraints of all their base types that interoperation is assured, regardless of what the intermediate constraints are, simply because everything involved in the two topics can be understood at some common level, even if the base markup (that is, the element types and attributers) of one topic would not be directly valid in the context of the other content.

 

That is, any process that presumes that two separate topics governed by two different shells must be DTD valid by anything other than a DTD reflecting the most general types is, I think, broken and not reflecting clear thought about how XML data *can* be processed. While there may be practical reasons to literally combine data so that the  combined result is valid against some DTD, there is nothing about DITA processing or semantics that I can see that *requires* it.

 

In particular, the expectation that one can cut-and-paste between any two topics as an editing process, which I think might be part of the driving motivation for these sorts of (what I see as) draconian constraints, is misplaced because it’s simply not practical without some intermediary that knows that the most appropriate mapping is between two different specializations.  For conref, there really should be no problem because conref should *not* be defined in terms of a copy but in terms of a “process as if” as there’s no *technical* requirement for conref to literally result in a new instance that reflects the resolution of the conref (even though that’s how the Toolkit works today).

 

That is, as long as all the class values are explicit, all DITA data (by which I mean elements that conform to all the rules of the types in their class hierarchy) is fully reliably  processable in terms of DITA-defined semantics.

 

In the case of allowing declaration modules to be combined, I think the existing system works pretty well and only requires allowing shell-level configuration element-type-specific content models to be fully flexible without reducing the plugability of modules (that is, the “only more constrained” rule must still hold). But I also can’t claim to fully understand what the rules are, partly because they don’t always make sense and partly because I’ve sometimes willfully ignored them when they got in the way of solving immediate problems J

 

Or maybe the easier solution is to do what DocBook has done and make Relax (and perhaps Schematron) the normative constraint expression mechanism—that would allow directly stating most of the constraints that need to be expressed, I think, and in a way that would be inspectable by humans and machines and already supported by at least some editors.

 

Cheers,

 

E.