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: Sun, 5 Mar 2000 02:20:51 -0600

> [Steve Newcomb on AFs]
> >When looking at such an element, select the attribute that
> >corresponds to the meta DTD you're interested in interpreting the
> >element as conforming to; the value of that attribute is the tagname
> >for all purposes of that meta DTD.)

[Sean McGrath:]
> In other words, (as I have said before, years ago
> on comp.text.sgml), there
> is nothing "meta" about meta DTDs.
> They are essentially, a device for
> simple one-to-one mappings of element
> type name to element type name with some
> extra bells on.
> In my world, this facility fails the "so what"
> test.
> Oh how I wish the real world were so simple,
> that a basic mapping system sufficed to
> get real work done.
> I cannot understand why people think
> that this capability solves so many
> real world problems. It doesn't in
> my experience.
> Simple mapping of source elememt type name
> to destination element type name makes
> up about 0.00001% of what I do in
> SGML/XML processing work. The
> other 99.00009% is made up of re-arranging
> sub-trees, collapsing strucures, expanding
> structures, hoisting content to attribute,
> dropping attributes to data content etc. etc.
> The declarative syntax of XSLT is a lot
> closer to the money for my work as it
> goes beyond simple element mapping and
> sub-tree pruning. Not that XSLT does
> not have its problems from my perspective
> but that is a different rant:-)

Sean, somehow you've completely missed the point of AFs.  AFs are not
about general transformations.  If you try to use AFs for general
transformations, you're exactly right: you'll quickly discover that
they don't do much for you.  They don't do nearly enough!  

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.  This situation is, if anything, even more untenable than
    the "everybody uses the same DTD" paradigm, because if any one DTD
    changes, N minus 1 transformation specifications must also change.
    The cost of maintaining the ability to interchange information
    throughout the industry increases geometrically as the number of
    different participants, each of whom has his own DTD.  It's
    economically crazy.  Large and diverse industries must be able to
    communicate, control of the syntax of messages must be
    distributed, and change must be accommodatable at low (or no) cost.

AFs provide a paradigm in which, *precisely because AF transformations
are so bloody limited in their transformational power*, everybody gets
to control their own DTDs, and, at the same time, everybody's messages
are interpretable and validatable as industry-standard messages.  No
transformation specifications are required.  If the industry-standard
meta-DTD changes, all the necessary transformation code is
automatically updated (since there is no such code).  If somebody
needs to change their own DTD, it causes no problem as long as they
don't prevent their messages from conforming to the inherited
industry-standard DTD.


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