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] Flatter is Better (part two)

Hi Roger,

maybe our beef with flatter being not better is proven by simple example.
It took the liberty of flattening your email below. Now, please inform us how this flatter version is better than the original..

XML is just a way to (mainly) hierarchically representing an object model.
How that model looks depends on the use. For GIS and route planning applications, it may make sense to have a model where you have a City node with Street nodes with House nodes, for postal and addressing purposes, not so much.

When developing an XML interface, you have to think of your internal model, as well as that of the models that others attach to the data.
In practice, most of the resulting XML interfaces only take into account the developer's own world view, even when that developer consists of an official committee for a e.g. a trade group.
Hence we had at some point 70 XML invoice models on a Microsoft website, each claiming to be the global invoice model, yet with no pair of them actually being interoperable. And that for a piece of information that is globally relatively uniform and very well understood!

Having been in B2B interactions for some 20 odd years now, I can tell you that finding the right model for a B2B document is not simple, and having XML in that area which claims to make it simple has paid my wages for a good part of that since I'm the one that ends up mapping all the variations to my customers' real world view, which is actually their ERP implementation.


On 12/3/2014 11:28 AM, Costello, Roger L. wrote:

hipeteryouwrotethatanxmldesignmusttakeintoconsiderationaprioriknowledgeabouttheenvironmentthatthedesignmustlivewithinbetterisdeterminedbytheneedsofthedataexchangepartnersandcanvarybyusecasenetworkbandwidthtargetdeviceandahostofotherconstraintshowdoesonedesignxmlintheabsenceofsuchaprioriknowledgethatishowdoesonedesignxmlthatcanbeusedoverlotsofdifferentnetworkswithlotsofdifferentbandwidthshowdoesonedesignxmlthatcanbeusedbylotsofdifferentconsumersapplicationswithwidelyvaryingprocessingneedsithoughtthatthewholepointofdesigningxmlistoavoidtyingadesigntoaspecificnetworkaspecificapplicationaspecificusecaseithoughtthatthewholepointofdesigningxmlistocreateadesignthatisusableacrosslotsofdifferentnetworksbylotsofdifferentapplicationsbylotsofdifferentusecasesithoughtthatthewholepointistofreexmlofsuchtetheringxmlrunfreeintheabsenceofaprioriknowledgewemusticontendstripawayallpreconceivednotionsoftherightxmlhierarchycontentthatswhataflatdesignprovidesitprovidesaseriesofcomponentsthatthatcanbemashe dupwithothercomponentscanbetransformedparsedintoanyhierarchyandcanbenormalizedstrippeddowntheflatdesignitseemstomerepresentstheultimategoalofxmlfreedomfromaprioriconstraintsknowledgexmldesignbeeternalcommentsroger

[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