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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: Architectural Forms and XAF

[ Lists Home | Date Index | Thread Index ]
  • From: "Steven R. Newcomb" <srn@techno.com>
  • To: digitome@iol.ie
  • Date: Tue, 7 Mar 2000 05:25:13 -0600

[Steve Newcomb:]
> >Now here's the real point.  Without AFs, there are only two choices,
> >in all cases where all the players in an industry must communicate
> >freely with each other:
> >
> >(1) Everybody has to use the same DTD or Schema (which ain't gonna
> >    happen for reasons too obvious to mention here), or
> >
> >(2) Everybody uses different DTDs, and, for N DTDs, there must be
> >    roughly N-squared transformation specifications to convert between
> >    them.

[Sean McGrath:]
> There are three choices - not two:-
>  (3) Agree an interchange DTD. For N DTDs, there are N transformations
>      to the interchange DTD. This is *exactly* what AFs do where
>      "interchange DTD" == "architectural DTD".
>      However, by choosing to use AFs for this, you (IMHO severly)
>      limit the degree of mapping between the source DTD and the
>      interchange DTD.
> I am a big fan of interchange DTDs. My experience,FWIW, is that
> the differences between DTDs that need to be mapped to an
> interchange DTD are almost always such that the transformation
> to the interchange DTD cannot be expressed with AFs.

It's true that the use of AFs places certain limits on what you can do
in instances that purport to inherit them.  That's the whole point!
The idea is to make sure that the information you're sending someone
is processable in terms of some higher, widely-agreed-upon model, an
"interchange DTD" (aka, in ISO terms, for better or worse, a "meta
DTD").  Your third choice methodology sacrifices the ability to
determine automatically whether an instance conforms to the
constraints expressed by the interchange DTDs into instances of which
it presumably can be transformed.  Therefore, your third choice is not
a realistic option if all the members of an industrial community must
communicate reliably and cheaply with each other, while accommodating
diversity and specialization.  Your proposed third-choice methodology
requires a distinct, separately maintained transformation
specification for every DTD; that's both expensive and unreliable.

Of course, if reliability is not important, there's no need for any of
this stuff; we don't need DTDs at all.  I realize that Web culture
does not place a high value on reliability, and that it places a very
high value on apparent simplicity, even when apparent simplicity
creates massive complexity and mountains of unnecessary work for
information managers.

B2B communications absolutely require reliability and predictable
results.  Accountability is vital.  Avoiding accountability is
popular, but the avoidance of accountability is not in the best
interests of the world economy as a whole.


Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 517 7954
fax    +1 972 517 4571

Suite 211
7101 Chase Oaks Boulevard 
Plano, Texas 75025 USA

This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS