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] Build applications using the "simplicity stack"

Aha, thank you. But I think to minimize the number of ways of representing the same data is only one facet of the story. For example, it is a typical situation that a particular item of information inevitably appears in both, relational tables and XML messages. What seems to me very important is the *alignment* of items, so that, for example, a <Flight> element and its contents (perhaps many items) can be clearly mapped to the relational representation. Simple example: { Flight/@FlightNumber <=> (Db=Flights/Table=Flight/Col=FLIGHT_NR) } I know that often it is not possible to do it as simply as that, and this is exactly the challenge!

We may think about novel approaches how to define and represent such alignment. In a way, we need a language how to express it, and express it uniformly, and ideally in a way supporting code generation, too.

To the extent that alignment can be accomplished in a satisfactory way, heterogeneity of outward representation much less affects the "uniformity of data model and data representations". My ideal is to think in terms of expressions - different expressions, same value.

My point of reference is Plato's cave: tell the shadows from the things.


Michael Kay <mike@saxonica.com> schrieb am 13:30 Freitag, 4.April 2014:

But I have yet a question. You wrote: "uniformity of data model and systems architecture across a system".

Actually I think I wrote "uniformity of data model and data representations".

By uniformity of data model I meant that all components of the system share the same understanding of the information that the system is handling. For example, a "flight" in one part of the system is the same thing as a flight in another part of the system, e.g. it doesn't suddenly become three flights just because three different airlines are selling it.

By uniformity of data representation I meant minimizing the number of different ways of representing the same data, e.g. in XML, in Java objects, and in SQL tables.

Michael Kay

Q: Do you mean uniformity *within* the data model and *within* the realm of representations; OR do you mean also a uniformity which *spans* across the gap between data model and representations, enabling clear alignments. The latter, by the way, was what I attempted to say (writing "establish the relationships between document content and system structure").

Michael Kay <mike@saxonica.com> schrieb am 11:00 Freitag, 4.April 2014:

On 4 Apr 2014, at 09:17, Hans-Juergen Rennau <hrennau@yahoo.de> wrote:

In response to Arjun Ray saying: "Data should be stored in formats appropriate to purpose. Systems are built to satisfy business requirements, not to propitiate theories."

Michael Kay wrote: "I think that kind of statement grossly undervalues the contribution that good systems architecture can make to business success."

Seen in the light of to what it responds, this is an amazing statement. Perhaps I misread it, but it suggests to me this thought: XML representation excels in the clarity and explicitness of structure; system architecture establishes important large-scale structures; XML representation can help to establish very clearly the relationships between document content and system structure - between document and large context, that is - and to align content items with items of system architecture.

I was not intending to suggest that a systems architecture has to be based on XML in order to be considered "good".

I do think that uniformity of data model and data representation across a system help enormously in ensuring the architectural coherence of the system, and an architecture based on end-to-end XML can help to achieve that goal.

Michael Kay

[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