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


Help: OASIS Mailing Lists Help | MarkMail Help



   Co-operating with Architectural Forms

[ Lists Home | Date Index | Thread Index ]

In [1], Steven Newcomb noted that:

>The Architectural Forms paradigm is strictly for people
>who *want* to cooperate with their various communities,
>but who can't base their cooperation on the strictest
>kind of adherence to a single monolithic document type.

And while Steven pointed out some advantages of AF 
based co-operation I still don't understand the process by 
which this co-operation is achieved. 

I *think* I understand AFs, at least from a high-level, but 
I'm stumbling over the application.

Consider the following:

I'm receiving XML from Company X. We've thrashed out a 
DTD (Format A), and their system produces data to this schema, and 
ours is built to process it.

Now Company Y wants to join in the fun, but they are already 
tooled up to produce Format B.

Taking a look at Format B I see that it contains the same basic 
information. So I write an XSLT transform to turn B -> A, and 
plug this into my system. I can now co-operate with both X 
and Y, without causing Y any additional work/difficulties.

How do AFs help in this situation?

I'll hazard a response to this question, just to outline my confusion.
For an AF based solution we get together with X and Y and define 
a meta-DTD. I then re-tool to process data according to the 
meta-DTD, and do the appropriate AF magic to process A & B 
according to this meta-DTD.

Isn't this more work?



[1]. http://lists.xml.org/archives/xml-dev/200201/msg01724.html

Leigh Dodds, Research Group, Ingenta | "Pluralitas non est ponenda
http://weblogs.userland.com/eclectic |    sine necessitate"
http://www.xml.com/pub/xmldeviant    |     -- William of Ockham


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

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