Re: [xml-dev] What's your ideology for how applications should be create

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

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@CraneSoftwrights.com
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