RE: Core Component Analysis - SWIFT's Comments

[Todd Boyle <tboyle@rosehill.net>]

Stephane said,
> need comments from .. people working on translation tools.

I advocate a simpler object hierarchy and converging the
layers of the protocol stack, so that ebXML messages can be
parsed by string parsers.  ebXML batting average should be
over 90% of the dollar volume of world trade, not requiring
middleware servers, XSLT or XML parsers.  But doable by only
string parsers, perl, python etc.

The rest of this message just explains why so skip it if you're busy.
I'm told nobody reads more than the first screen of my posts anyway! :-)

Adoption of ebXML by SMEs depends on the smaller, more competitive
software vendors.  They will certainly adopt it faster if they can
figure out a way to import/export ebXML transactions without
large XML parsing and XSLT translation infrastructures.

Web developers and software developers are going to participate in
particular, exact ecommerce interactions without any middleware whatsoever.

Developers will figure out what the documents look like and parse them
correctly by their own means, i.e. without quarterly updates of their
XML parser from you- know who, which are unreliable and break their
other software, and drive you inexorably to upgrade your OS and other
tools.

There are many good software companies out there who will not build
business applications on any of the top 5, competing XML parser/dev
platform/database/middleware platforms.  Reason: betting years of
learning curve is risky for the developer personally, and tying
yourself to these platforms commits you (and all of your customers)
to the platforms which then, always, extract as much rent as they
possibly can.  Market forces commoditize the developer, the developer
is pitted against other developers in a vicious circle, and they
then have no option but to go forth and try to enslave the whole
economy in rent extraction models.

Small business knows this and avoids two things like the plague:

 1. lock-in, and
 2. complexity.

There are two impediments to adoption of ebXML by the string parsing-
perl scripting sorts of developers:  (1) It may be impossible if ebXML
interactions are excessively interactive, i.e. the numbers of branches
and permutations that must be supported is too large, or the shape of
the XML messages themselves is dynamic so cannot be predicted even for
specific interactions like sending or receiving a PO. This surely will
not happen.  The other impediment is (2) that the developer is
overwhelmed in endless object hierarchies, making it so complex to code
their string processor that parsing outside of bigtime XML
infrastructures is either impossible or they cannot compete,
commercially, with the big expensive development platforms.  That seems
the bigger risk, to me.

Accordingly I would vote for <PartyBirthDate> below, and slam it right
into the Party schema along with 100 to 200 mostly optional elements
in the root level.   Give me a flat Party Schema.  Please.

And I agree with Phil.

I seem to notice in designing a schema for General Ledger, that
whenever we decide to put an element on the header of the journal
entry rather than the row (for example, transaction date) there is a
systematic problem that always results: any software application that
handles that element on a row instead of the header is impossible
to support with that schema.  However, the converse is not true:  if you
put an element on the row which is handled in the header by some
application, the application can still talk to the schema by repeating
the date in every row of the transaction.

Therefore if you want to optimize for compatibility you might want to
use a flat schema.

XML messages will certainly be compressed in the long term.

Small business has a number of good reasons to delay adopting complex
hierarchic schemas for their business data.  If Enterprises build
complex hierarchic transaction schemas they face significant risk
that SMEs won't use them.

Todd Boyle, cpa - www.gldialtone.com - webledger guy.


<Stephane Canon>
   We have different implementation proposals:

   ebXML Core Component:

   <Party> .
    <Date/Time>
      <Date>20010101</Date>
   <Time>102300</Time>
   <PurposeCode>birthdate<PurposeCode>
   ..
    </Date/Time>
    <Date/Time>
      <Date>20800202</Date>
   <Time>102300</Time>
   <PurposeCode>DeathDate<PurposeCode>

    </Date/Time>
   .
   </Party>

   SWIFT:

      <Party> ...
         <BirthDate>
            <Date>20010101</Date>
            <Time>102300</Time>
            ..........
         </BirthDate>
         <DeathDate>
            <Date>20800202</Date>
            ..........
         </DeathDate>
         ...........
      </Party

   another one:

      <Birth>
         <Date>1922-10-16</Date>
         ..........
      </Birth>

   The BSR proposal would be something like that:

   <PartyBirthDate>1922-10-12</PartyBirthDate>

   Let's try to determine what is the best representation ... We need
   comments from the people involved with the BSR intiative, from the
   XML experts and from people working on translation tools.
</Stephane Canon>
<William J. Kammerer>
   > > Finally, Phil asks "how are we going to deal with many to many
   > > relationships within an XML hierarchy. I am sufficiently old/mature
to
   > > remember the problem  we had with such things in Hierarchical
databases
   > > and the factors which led to Relational Databases where relationships
   > > are made at run time. With XML we seem to be back to hierarchies
which
   > > may lead to similar difficulties."  I am far too young to answer
this.
   > > I will have to yield to Bob Miller.
</William J. Kammerer>