I'm not sure about the should vs must
being a typo. I think it's currently must, and on purpose.
One of the hoped-for benefits is the
ability to auto-assemble new shell doctypes from a library of modules,
including ones coming from different organizations. That's one of the things
we had potentially being contributed to the TC earlier this year from Jarno
Elovirta, as I recall. I don't know what the status of that particular
project is, but the goal remains viable.
If we do soften it to "must",
it would need to be with warnings along the lines of:
"Failing to follow modularization
practices may result in doctypes that cannot be shared or integrated with
other organizations using any tools that depend on the modularization spec.
Although your content will be interchangeable, your specialization designs
will not be."
With regards to generalization/respecialization:
that's tangential to the question of modularization. Modularization makes
it easier to create new hybrid doctypes, but is tangential to the question
of whether to generalize doctypes or share them.
Michael Priestley, Senior Technical
Staff Member (STSM)
Lead IBM DITA Architect
http://dita.xml.org/blog/25
Dana Spradley <>
07/06/2009 06:48 PM
To
Eliot Kimber <>
cc
Subject
RE: [dita] Conformance and interoperability
Thanks Eliot - that's the piece I was missing I think.
Although I think the module design is, technically, a different "conformance
target" from the document instances. But so long as it's a SHOULD
- and not a "mandatory implementation design pattern" as I think
it's phrased now - I guess I'm okay with it.
Indeed, if it weren't a different conformance target, there'd be no need
for generalization and re-specialization, would there?
Since you could just exchange the vocabulary modules to interoperate -
instead of the generalized document instances.
--Dana
-----Original Message-----
From: Eliot Kimber [mailto:]
Sent: Monday, July 06, 2009 3:13 PM
To: Dana Spradley; dita
Subject: Re: [dita] Conformance and interoperability
The interoperability that the design pattern requirements serve is
interoperability of vocabulary module design and implementation. That is,
by
defining a consistent design pattern for implementing vocabulary modules,
DITA ensures that such modules are themselves interoperable among both
people who understand DITA and tools that work on modules as artifacts
(that
is, tools that support the creation, modification, and management of
vocabulary and constraint modules).
Note that design pattern usage is a SHOULD not a MUST. If that is not clear
in the current draft then that's my editorial error and it needs to be
corrected.
DITA is not just about document instances, it's about systems of
information, and that system includes the vocabulary definition
implementations too.
For example, if you interchange DITA content with another party and you've
developed specializations for that content you will be supplying the
vocabulary modules along with content (you have to, otherwise the other
party has no way to process or validate the content you're supplying).
It
will be much, much easier for the other party to understand, and build
on,
your vocabulary modules if they follow the standard design pattern than
if
they don't.
When I first came to DITA I couldn't understand why it imposed what seemed
like very odd ways of setting DTDs. But once I started doing specialization
work, I came to realize that it is exactly those design patterns that help
make developing new DITA-based XML designs *10 times faster* than it has
ever been before, because the design patterns make the implementation almost
entirely mechanical.
Cheers,
Eliot
On 7/6/09 5:01 PM, "Dana Spradley" <>
wrote:
> Perhaps someone with more experience setting standards that I can
help me -
> this TC is my only exposure to such work - but after looking into
the RFC
> everyone subscribes to regarding key words for requirement levels
-
> http://www.ietf.org/rfc/rfc2119.txt - in order to review the
> "Specialization..." section of our draft 1.2 architectural
spec, I must admit
> I'm a bit confused by some of what we seem to be doing in it.
>
> The RFC says such imperatives "must not be used to try to impose
a particular
> method on implementors where the method is not required for interoperability."
>
> So I take it that as long as my implementation can supply DITA-compliant
XML
> document instances to another party - and accept such instances from
them -
> this TC has absolute no right to legislate the particular mechanisms
I use to
> do that.
>
> For example, I may map DITA elements and attributes onto an entirely
different
> XML vocabulary and process this non-DITA vocabulary using an architecture
of
> my own design, and so long as I transform them back to DITA before
sending
> them off - I've fulfilled my end of the interoperability bargain.
>
> Is that everyone's understanding here?
>
----
Eliot Kimber | Senior Solutions Architect | Really Strategies, Inc.
email: <mailto:>
office: 610.631.6770 | cell: 512.554.9368
2570 Boulevard of the Generals | Suite 213 | Audubon, PA 19403
www.reallysi.com <http://www.reallysi.com> | http://blog.reallysi.com
<http://blog.reallysi.com> | www.rsuitecms.com <http://www.rsuitecms.com>
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
