RE: eDTD BUSINESS SCHEMAS

[Keith.Finkelde@BTFinancialgroup.com]

David

I have reviewed some of the bizcodes DTDs you have referred to.

How many semantic abiguities are contained in the following?   -  Too many to mention!!!.   

  <?xml version="1.0" ?>
  <!-- This is the eDTD for passenger details -->
  <eDTDstructure>

   <ELEMENT name="rootXML" model="(name,account)" />
   <ELEMENT name="name" model="(title,lastname,first,initials,credentials)" />

   <ELEMENT name="title" type="select" mask="ULLL" values="Mr.|Mrs.|Ms.|Sir" default="Mr." />
   <ELEMENT name="lastname" type="string" mask="X35" required="true" />
   <ELEMENT name="first" type="string" mask="X15" />
   <ELEMENT name="initials" mask="U4" />
   <ELEMENT name="credentials" mask="UXXXXX" />
   <ELEMENT name="account" mask="U#7" required="true">
    <ATTLIST attr.name="type" values="ATA|Cust|Other" required="false" default="Cust" />
   </ELEMENT>
  </eDTDstructure>


I think we need explicit qualified naming of all attributes - in the context they are being used.

There seems to be another myth that the XML is going to stand alone without a reference to a semantic definition, and that the 
syntax neutral representation will be an export to XML, not a genuine transformation.  All steps through a MDLC (Message Development LifeCycle ) will
require a transformation (that is a trade-off of the different decisions we need to make at different life cycle stages).  Note: some OO methods  also promoted the 
existence of the same business concept throughout the whole SDLC , without the need for transformation, and have failed in the business world. 
My experience is that - business analytic representations [problem space] need multiple transformations prior to designs [logical solution] 
then transformation to a technical language [physical solution].

We have been actively using UML in the logical solution space-  (Message Class Models + Integrity Constraints + Formating Rules ) expressed in a combination of Rose models  + Word docs,then XML Authority to transform this to a dictionary ( currently - not able to express all cross field constraints) then export/generate to XML protocols (of whatever dialect) [physical solution].

look forward to other comments.

regards 

Keith Finkelde 
BT Portfolio Services
email: keith.finkelde@btfinancialgroup.com
phone: +61 2 9259 9765



-----Original Message-----
From: David RR Webber [mailto:Gnosis_@compuserve.com]
Sent: Tuesday,29 February 2000 3:47
To: ebXML Core Components
Subject: eDTD BUSINESS SCHEMAS


 http://www.bizcodes.org/eDTD/xml-eDTDWP.htm

Please review the above content. You can download the XML
and review the example in any XML capable tool.

I'm intrigued by how this compares to Martin's approach at:

 http://www.sgml.u-net.com/neutral.htm

Basically I would characterize that the difference is between
'explicit definitions' as opposed to 'implied definitions'.

There's a lot to like about both approaches, and clearly
blending the two has significant merit and possiblities.

Martin's approach is clearly designed to be 'schema neutral'.
While this has a lot of attractions - foremost is HIDING the worst
aspects of Schema - the unreadablity - the devil is in the detail
and the heavy reliance on a Repository to allow you to figure out
what a :

<InformationMessage ID="DespatchNote">
  <GlobalID>LGMS12345</GlobalID>
  <Name>Despatch Note</Name>
  . . . . . .

really is.

Anyway - one thing is abundantly clear to me - the current
W3C Schema proposal is coming up way short and way too light
compared to these business focused approaches.

I'm particularly disturbed by the use of MAXOCCURS / MINOCCURS.
This I believe is a recipe for disaster on a global scale - that can 
cost implementers hundreds of millions $$$ annual resolving data
conflicts that this mechanism will foster and encourage.

Fortunately we have the ebXML initiative - and the ability to make
the business requirements drive the technical syntax.

I look forward to people's comments - refinements - and ideas to
help create the right technology tools here.  Of particular importance
is to take these ideas and IMPLEMENT one of your own transactions.

This will teach and instruct on what is really needed.  I'm particularly
focused on creating a Schema system that you can manually type in,
and read, understand, and above all keep elegantly simple.

That path leads to success in a global context.

So we have the two levels - the top level, and the bottom level.
The top level allows modelling of the business process, the 
bottom level provides succinct machine syntax to implement,
support and effectively manage those top level processes 
using computer systems and XML syntax.

This synergy I believe is at the heart of the ebXML effort and
what we need to achieve over the coming months.

Thanks, DW.