|
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. --Gait. On 12/3/2014 11:28 AM, Costello, Roger
L. wrote:
hipeteryouwrotethatanxmldesignmusttakeintoconsiderationaprioriknowledgeabouttheenvironmentthatthedesignmustlivewithinbetterisdeterminedbytheneedsofthedataexchangepartnersandcanvarybyusecasenetworkbandwidthtargetdeviceandahostofotherconstraintshowdoesonedesignxmlintheabsenceofsuchaprioriknowledgethatishowdoesonedesignxmlthatcanbeusedoverlotsofdifferentnetworkswithlotsofdifferentbandwidthshowdoesonedesignxmlthatcanbeusedbylotsofdifferentconsumersapplicationswithwidelyvaryingprocessingneedsithoughtthatthewholepointofdesigningxmlistoavoidtyingadesigntoaspecificnetworkaspecificapplicationaspecificusecaseithoughtthatthewholepointofdesigningxmlistocreateadesignthatisusableacrosslotsofdifferentnetworksbylotsofdifferentapplicationsbylotsofdifferentusecasesithoughtthatthewholepointistofreexmlofsuchtetheringxmlrunfreeintheabsenceofaprioriknowledgewemusticontendstripawayallpreconceivednotionsoftherightxmlhierarchycontentthatswhataflatdesignprovidesitprovidesaseriesofcomponentsthatthatcanbemashe dupwithothercomponentscanbetransformedparsedintoanyhierarchyandcanbenormalizedstrippeddowntheflatdesignitseemstomerepresentstheultimategoalofxmlfreedomfromaprioriconstraintsknowledgexmldesignbeeternalcommentsroger |