Cart
[Home] [By Thread] [By Date] [Recent Entries]
Horses for courses. I'm uncomfortable, Roger, that your summary is only appropriate for a small number of applications, but is being put forward as some kind of rule of thumb that might give a myopic view to new users of XML reading the archive. At 2008-12-20 08:12 -0500, Costello, Roger L. wrote: >Create workflow-based applications. Design XML documents to mimic >documents in the physical world. This might be fine for those who are modeling paper, but when paper is merely a physical expression of something going on behind the scenes, then mimicking documents might very well be totally inappropriate. A real-world example of this are the diametric approaches to model an invoice described by the Universal Business Language and by UN-eDocs: UBL models all of the information necessary for 31 business transactions in XML such as invoice, order, etc., and from that information can produce any paper form including UN trade documents: http://docs.oasis-open.org/ubl/os-UBL-2.0/UBL-2.0.html http://docs.oasis-open.org/ubl/UBL-2.0-update.html UN-eDocs models the physical UN trade paper documents themselves in XML: http://www.unece.org/etrades/unedocs/ I would think that ERP system and business requirements would be more easily met with an abstract definition of all required information, and then users can make as many and varied "documents in the physical world". I make stylesheets publicly available that convert a UBL invoice into the UN trade document with the user's choice of 14 different languages for the box labels. I feel working with UBL would be more flexible than working with UN-eDocs and would meet a broader set of requirements. >Store the XML documents centrally, in an XML database. Pass around >URLs to the documents. Isn't that a single point of failure? Isn't that a challenge for access rights management and other security issues when many parties are involved? Consider the Electronic Freight Management system created by the US Department of transport: http://www.metrans.org/nuf/2007/documents/Onder.pdf (esp. slide 10) http://projects.battelle.org/fih/ http://projects.battelle.org/fih/Value.htm In order to satisfy a single "transportation status" requirement, 14 different parties involved in shipping Victoria Secret clothing (nice project!) from China to Columbus Ohio created an SOA interface to their respective disparate and proprietary systems. Each participant was responsible for maintaining *only* the information they knew about and were in control of, and no-one was responsible for anyone else's information. Any individual then wanting the status of a package would trigger a federated query across all 14 parties using the SOA interface, and each system created a UBL Transportation Status Message in response: http://docs.oasis-open.org/ubl/os-UBL-2.0/xsd/maindoc/UBL-TransportationStatus-2.0.xsd The query software then aggregated as many of the 14 UBL documents that actually arrived in response, massaging the information in the standardized structures and creating a single status HTML page presented to the individual. Whether that individual then wanted to then save that snapshot of the status was up to them ... the query was done. Each party managed only their own security and access. Each party managed only their own data, back-end system and SOA interface. If any one party was down, the individual still would still get status for 13 segments of the transport event. XML presents the opportunity for parceling out information only to responsible parties by being the platform- and application-independent bridge for conveying only what is needed, and when using SOA, to only those who are authorized to see it. I also see this in publishing where XSLT 2 aggregates information from multiple XML documents from different company sources into a single XSL-FO result. This is the antithesis of your suggested "Store the XML documents centrally", but it doesn't nullify your suggestion, it is just another approach to your question of "how applications should be created". >Use an all-XML solution; avoid using imperative languages. How about "use XML languages where XML is being used, and use the most appropriate language for the application working on the information"? Consider that I might have highly-computational requirements implemented in FORTRAN? Would I change that to XSLT 2.0 just because my data is in XML? No. I might use XSLT 2.0 to convert the data into a format suitable for my FORTRAN program to act on, and then XSLT 2.0 to convert the result back to XML for transmission again, but I wouldn't move away from FORTRAN. At the XML'2008 conference earlier this month, the closing panel discussion focused on application development with XML and making XML faster, and what the future is for XML. I brought up from the audience in the Q&A that we cannot lose sight of the use of XML for interchange, and that perhaps shoehorning XML structures into application programming paradigms isn't very relevant. Use XML to get the information from point A to point B, then use whatever representation makes sense for your applications and your algorithms and your imperative languages and your spreadsheets and whatever else makes sense for the nature of the information. And I don't think XML is the first choice for internal application program representation. >What's your ideology for how applications should be created? "Horses for courses" I hope this is considered helpful. . . . . . . . . . . Ken -- Upcoming XSLT/XSL-FO, UBL and code list hands-on training classes: : Sydney, AU 2009-01/02; Brussels, BE 2009-03; Prague, CZ 2009-03 Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video Video sample lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg Video course overview: http://www.youtube.com/watch?v=VTiodiij6gE G. Ken Holman mailto:gkholman@C... Crane Softwrights Ltd. http://www.CraneSoftwrights.com/x/ Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/x/bc Legal business disclaimers: http://www.CraneSoftwrights.com/legal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
