Re: Core Component Analysis - SWIFT's Comments

[Martin Bryan <mtbryan@sgml.u-net.com>]

Two points re Todds comments:

> 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.

We need to remind ourselces that one of the stated goals of ebXML is to
allow SMEs to use their existing Web tools to handle EDI messages without
having to purchase EDI specific tools. This is why I have been insisting
that we use standardized XML techniques (W3C XML Schemas and XSLT) rather
than developing ebXML specific ones. Whilst I seem to be loosing this battle
in the context area, I feel that any solution that is not processable by a
standard Web browser without having to install ebXML specific software will
represent a complete failure of the mission of ebXML.

>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.

You seem to contradict yourself in these two adjacent paragraphsTodd. If you
have
<Party>
   <Birth>
      <Date>
rather than <PartyBirthDate> you can write one routine for handling date
processing that will work for any date in any message. If you require each
date element to be uniquely named then you must repeat the relevant process
for each applicaiton of the concept within the document set. This is
distinctly not a good idea from the program maintenance point of view,
whether you are using string processing or hierarchical processing.

Martin