[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Groups - Proposal 12008 - vocabulary and integrationconstraints (HTML) (IssueConstraints12008.html) uploaded
|
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. ---- W. Eliot Kimber Senior Solutions Architect Really Strategies, Inc. 512 554 9368 From: Erik Hennum
[mailto:ehennum@us.ibm.com] Hi, Eliot:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]