[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: eDTD BUSINESS SCHEMAS
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: firstname.lastname@example.org 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.
Powered by eList eXpress LLC