Were constraints an off-the-list 1.1 item? Too bad we couldn't get to them last time.
In any event, having just implemented a customization myself to eliminate many unneeded elements and attributes from the content model - but in the fashion of a strict subset, so that full compatibility is assured (well, except for a few renamings) - I can attest to how valuable this systematic solution might be - at least in the document type shell file
On the other hand, since my document instances retrieve their schemas from a webserver, I'd probably resort to customization anyway on the Mod and Grp files, to eliminate the performance hit of retrieving and parsing so many unused elements and attributes when opening a document.
--Dana
Erik Hennum wrote:
Hi, Eliot:
Good design pattern -- probably even be a best practice for DITA 1.1 specializations.
I do wonder whether the applicability of this pattern to many cases means, paradoxically, that we shouldn't introduce a specific element for the individual case. For instance, the pattern also applies to a context of mixed text with blocks (as in <section>, <p>, <entry>, or <itemgroup>).
The other consideration might be that, if we can come up with an acceptable implementation to the constraints proposal, we could apply the constraint to the content model and remove the need to specialize:
(Assuming we can come up with a constraints implementation that can be detected at runtime to determine interoperability, that packages constraints in reusable modules, that applies constraints to specializations, and that doesn't require an inhumanly complex design pattern for the DTD and XSD implementations.)
Hoping that's interesting,
Erik Hennum
ehennum@us.ibm.com
"W. Eliot Kimber" <ekimber@innodata-isogen.com>
"W. Eliot Kimber" <ekimber@innodata-isogen.com>
02/28/2007 08:12 AM
To
<dita@lists.oasis-open.org>
cc
Subject
[dita] 1.2 Feature Suggestion: <text> element
At least with DITA 1.1, where we can't add attributes, a reasonably
common pattern is this (using the base types, which would normally be
specialized for a specific application):
<ph>
<data/>
<ph>Text content of the phrase</ph>
</ph>
...
Given the general utility of this pattern, it seems reasonable to
provide the "text" specialization of "ph" as a base type so specializers
don't have to repeatedly re-invent it.
