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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Co-operating with Architectural Forms

[ Lists Home | Date Index | Thread Index ]


Leigh Dodds wrote:
>
> I'm receiving XML [in Format A] from Company X. [...]
> 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?

They can help in the case where Format B contains all the
data you need for a particular process, but cannot be
converted into a full instance of Format A.

Architectural schemas are usually much simpler than source
document schemas, and source schemas often reference multiple
architectures.  If Format A conforms to Architectures M, N, and O,
and Process P is based on Architecture N, then to get Process P
to work with Format B, it suffices to map Format B to Architecture N.
This should be easier than converting Format B to Format A (which
might not even be possible).

A slightly more concrete example: suppose Company X is providing
you newsfeeds in ComplicatedNews-ML, and you're producing daily
headline summaries (among other things).  Company Y uses
SimpleNews-ML, which can't be converted to ComplicatedNews-ML
because it's lacking certain required data.  Or the other way
around, but ComplicatedNews-ML can't be converted to SimpleNews-ML
without losing information.  However, both formats can be mapped
into the HeadlineSummaryArchitecture (which probably looks a lot
like RSS).  If you base your process on the HeadlineSummaryArchitecture,
instead of either of the concrete schemas, then you can handle
data from both companies.


>
> 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?

Not necessarily.  In many cases doing an architectural
transformation followed by architectural processing can
be simpler than a one-phase process that works directly
off the source document.

Also, it's easier to map N document types to an architecture
and do M things with the architecture than it is to do M things
with each of N document types, for large enough values of M and N.



--Joe English

  jenglish@flightlab.com




 

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

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