Lists Home |
Date Index |
You best bet is probably to look at some of the existing Schema Design
methodologies and their corresponding schemas. Instead of trying to
re-invent the wheel, you might find something that you can use in OASIS
UBL repository or the OAG's (Open Application Group). OAG definitely
promotes component reuse, and provides a standard BOD design methodology
that can be applied to your various business requirements. If you are
in the electronics industry you might want to check out RosettaNet and
see if their messages will work.
The advantage to using these message formats is that you start to
standardize the messages, and your trading partners or internal business
entities can start communicating in a standard format. It all depends
on how much leway you have in redesigning your existing Schemas.
Bullard, Claude L (Len) wrote:
> Hmm. Is there is an optimum trading strategy
> for schemas among trading partners with dissimilar or
> similar schemas where the payoff is minimum transformation
> of one or another document collection? In other words,
> given multiple partners who have started independently
> and now want to merge their collections, what is the
> optimum strategy for trades of production for production?
> Will degrees of similarity change the strategy?
> Are some productions of higher value than others
> (similar to playing poker)?
> If treated as a game, how many Nash equilibrium exist?
> What kind of game is this? (given perfect knowledge
> vs. incrementally acquired knowledge, competition vs.
> coordination: remember, standards are a coordination
> game to create a condition of a stable equilibrium)
> Given closed and open formats, this may not be a
> merely theoretical thought experiment.
> Game theorists? Schema negotiators?
> From: Michael Kay [mailto:firstname.lastname@example.org]
>> My question is: assuming I've created a schema for my old set
>> of documents,
>> if I were to create a transformation T1 that, given the old schema,
>> generates the new schema, could I machine-generate from that
>> T1 another transformation T2 that could be applied to the documents
> It's easy to demonstrate that this is impossible in general. Given a schema
> <p>Some <i>text</i> in italics</p>
> and another schema for
> <para>Some <italic>text</italic> in italics</para>
> It's clearly impossible to deduce the transformation by looking at the
> schemas alone.
> There are plenty of tools out there (generally called "mappers") that allow
> you to design a transformation starting from two schemas, by showing the
> relationships between the elements in each. They only work where the two
> schemas are quite similar, but that's probably true in your case.
> Michael Kay
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>