[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Co-operating with Architectural Forms

• To: "xml-dev" <xml-dev@l...>
• Subject: Re: Co-operating with Architectural Forms
• From: Joe English <jenglish@f...>
• Date: Wed, 30 Jan 2002 11:36:24 -0800
• In-reply-to: <NCBBKFMJCLIMOBIGKFMJMEAIHCAA.ldodds@i...>
• References: <NCBBKFMJCLIMOBIGKFMJMEAIHCAA.ldodds@i...>

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@f...

• Follow-Ups:
  • Re: Co-operating with Architectural Forms
    • From: Joe English <jenglish@f...>
  • Re: Co-operating with Architectural Forms
    • From: Joe English <jenglish@f...>
  • Re: Co-operating with Architectural Forms
    • From: Ronald Bourret <rpbourret@r...>

• References:
  • Co-operating with Architectural Forms
    • From: "Leigh Dodds" <ldodds@i...>

• Prev by Date: Re: Re: Auto-completion in editors
• Next by Date: Re: QNames in attribute values
• Previous by thread: Co-operating with Architectural Forms
• Next by thread: Re: Co-operating with Architectural Forms
• Index(es):
  • Date
  • Thread