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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Lessons learned from the XML experiment

Original Message From: "Uche Ogbuji"
On Fri, Nov 15, 2013 at 10:56 AM, Pete Cordell <petexmldev@codalogic.com>wrote:
Loose architectural systems, where clearly identified external
dependencies are injected in and resolved and dispatched via external
configuration are likely to be much more flexible than a system that has to
be crafted with intimate knowledge of a pipeline of how the data should be

This might be a matter of how we read what Hans-Juergen wrote, and I admit
I might have misread it. When he said "integrate schema information from
283 different schemas" that to me is not a loose architectural system. If
he had said "integrate data from 283 different schemas" then I'd agree.

In other words, for me, the right, loosely-coupled approach approach would
not be to make a super-schema with all its requisite entanglements from 238
initial sources, and then use that to direct all the processing. But
rather to use pipelines, with some sort of demultiplexer component at the
input to identify sub-patterns (maybe even at a greater level of
granularity than the 238 full schemata) and forward to specialized pipeline
branches for each. It wouldn't magically transform into an easy task, but I
believe it would be more manageable.
We're definitely on the same page here, perhaps tackling it in different ways. Yesterday we discussed <employer> vs. <com.example.employer>. One way to tackle different types of employer, say private, government, and, say, Australian (vs. UK/US etc) might be to make a super encompassing <employer> type. An alternative might be to use <com.example.employer> (the one we initially designed our system to handle), <com.example.employer.government> and <au.com.example.employer> each designed for their own needs, (but hopefully some loose knowledge of each other so you can use something akin to duck typing) and dispatch and handle them as needed.

But I guess there's many ways to skin a cat!

Pete Cordell
Codalogic Ltd
C++ tools for C++ programmers, http://codalogic.com
Read & write XML in C++, http://www.xml2cpp.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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

Copyright 1993-2007 XML.org. This site is hosted by OASIS