OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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:ekimber@reallysi.com]
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" <dana.spradley@oracle.com> 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:  ekimber@reallysi.com <mailto:ekimber@reallysi.com>
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 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]