dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] Groups - Proposal 12008 - vocabulary and integration constraints(HTML) (IssueConstraints12008.html) uploaded
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "Eliot Kimber" <ekimber@reallysi.com>
- Date: Tue, 21 Aug 2007 15:02:07 -0400
I think this is exactly parallel to
the domains attribute, and serves a parallel purpose - communicating constraints
for those processes that care. We've established previously that you generally
don't care, but that others do :-)
We can have yet again the argument about
how or why some companies want to compare constraints when reusing (ie
I want to know if you're allowing things that will blow up my processor).
But we got nowhere last time.
Michael Priestley
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
"Eliot Kimber"
<ekimber@reallysi.com>
08/21/2007 02:42 PM
|
To
| dita@lists.oasis-open.org
|
cc
|
|
Subject
| RE: [dita] Groups - Proposal 12008 -
vocabulary and integration constraints (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]
Sent: Tuesday, August 21, 2007 12:11 PM
To: Eliot Kimber
Cc: dita@lists.oasis-open.org; Grosso, Paul
Subject: RE: [dita] Groups - Proposal 12008 - vocabulary and integration
constraints (HTML) (IssueConstraints12008.html) uploaded
Hi, Eliot:
The proposal leverages standard DTD and Schema capabilities to implement
the constraints (with content model parameters in DTD and with class redefines
in Schema for constraints on content models). That is, the validation of
constrained document instances is plain old XML.
The concern is that about what happens if those implemented constraints
aren't declared and managed. If they aren't recognized by the DITA architecture,
the design is an unknown customization, the content is no longer DITA content,
so the interoperability warranty is broken.
Instead, the proposal declares and manages the set of safe customizations
so that
- The content conforming to a customized
design can still be regarded as DITA content
- The customizations are pluggable
into DITA document types and reusable across document types (including
across organization boundaries)
- Processors can recognize customizations
and detect when customized content is compatible with other DITA designs
(customized or not)
Hoping that clarifies,
Erik Hennum
ehennum@us.ibm.com
"Eliot Kimber" <ekimber@reallysi.com> wrote on 08/21/2007
08:18:07 AM:
> I tend to agree with Paul on this one. I’m having a hard time seeing
> how this is doing anything that can’t be done simply by providing
> content model parameters for each element type, which can then be
> tuned on a per-shell basis to impose whatever constraints are desired.
>
>
>
> From: Grosso, Paul [mailto:pgrosso@ptc.com]
> Sent: Tuesday, August 21, 2007 9:26 AM
> To: dita@lists.oasis-open.org
> Subject: RE: [dita] Groups - Proposal 12008 - vocabulary and
> integration constraints (HTML) (IssueConstraints12008.html) uploaded
>
> If I'm reading this correctly, it sounds like we are augmenting DTD
> constraints with some home brew syntax and semantics that users will
> need to learn and understand and implementors will need to implement.
>
> It sounds to me like some of these more complex proposals are just
> piling completely new concepts on top of an already complex
> application. Am I the only one somewhat concerned with the
> complexity we are adding to DITA?
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]