• From: Dimitre Novatchev <dnovatchev@g...>
• To: "Costello, Roger L." <costello@m...>
• Date: Fri, 4 Sep 2015 07:30:58 -0700

>
> Question: What data field(s) would you put into your data model to support your application in adapting to a constantly changing data provider topology?
>

At least the following seem necessary:

1)  A dataProviderId  in every document that we receive from a data provider
2)  A documentTypeId in every document that we receive from a data provider

3)  A DataProviders document (or collection of documents). Each
dataProvider document has a dataProviderId  (which could even be the
name of the document)
4)  Each dataProvider document contains among other things a list of
primary (top-level) schemas, and each primary schema describes one or
more document types -- these are identified by a documentTypeId as
described in 2) above.

5). For each DataProvider and documentTypeId supported by the
provider, an Id of a transformation that converts an original document
to a document in **normal form**. The idea is that upon receiving a
new document from any provider, we convert it to a single, normalized
type so that we can process documents by different providers using a
single set of document-provider-independent applications. This is a
common design pattern, reducing the number of required processing
applications from m*n to m + n, where m is the number of providers and
n is the number of different processing apps needed on the data.


More could be added if more concrete requirements are provided. For
example: validity, reliability, expiration date, membership in
different groups, relationships between different providers,..., etc.

Cheers,
Dimitre





On Fri, Sep 4, 2015 at 4:53 AM, Costello, Roger L. <costello@m...> wrote:
> Hi Folks,
>
> Scenario: You have an application that receives data from a set of data providers. The application operates over a long period of time. The set of data providers is constantly changing. You are designing a data model for use by the application and data providers. A design goal of your data model is to support the constantly changing data provider topology.
>
> Question: What data field(s) would you put into your data model to support your application in adapting to a constantly changing data provider topology?
>
> /Roger
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@l...
> subscribe: xml-dev-subscribe@l...
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php



-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
To achieve the impossible dream, try going to sleep.
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's works in 200yrs.Will they
write all patents, too? :)
-------------------------------------
Sanity is madness put to good use.
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.

• References:
  • Data fields that support adapting to a constantly changing dataprovider topology?
    • From: "Costello, Roger L." <costello@m...>