Lists Home |
Date Index |
In , 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?
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