RE: eDTD BUSINESS SCHEMAS

[David RR Webber <Gnosis_@compuserve.com>]

Keith,

Thanks for the note - when is a name not a name, but a named name naming
a name, huh?

Think we can tidy this one up with some tweeking.  I probably ought to
breakdown
and use the e: name space for eDTD, then  ->   e:name="name"  is more
clear.

Otherwise your message steps down into dark and murky waters.  I think I'm
on 
the right side of this abyss (?!) - namely providing the semantic
definition reference,
although of course we're NOT showing that in context.  Actually that - as
you note -
is an entirely spearate exercise!  At least here we are identifying the
exact orange,
its size and shape  - then you can know to put it into the exactly right
orange press
that suits your business process!  One step at a time....

Thanks, DW.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Message text written by INTERNET:Keith.Finkelde@btfinancialgroup.com
>   <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 <