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

Re: Lessons learned from the XML experiment

  • From: "Pete Cordell" <petexmldev@codalogic.com>
  • To: "Uche Ogbuji" <uche@ogbuji.net>
  • Date: Fri, 15 Nov 2013 18:51:41 -0000

Re:  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
processed.

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]


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.