Forgive the "Big Picture" view that follows, that always seems to upset so many list participants (until the seeds take root). Rachel: Looking at the dawning horizon of our aggregate technical and managerial capability, I concur with your assessment, and would suggest an even deeper connection into business, on an unbounded global scale. XML/EDI and EDI information products (syntax + semantics + medium) are at the top of a "pyramid" of - information systems, - on an IT architecture, - guided by an IT architecture, - for business processes, - within business functional organization, - resulting from business strategies, - in pursuit of business performance measures (objectives, SLA's, QOS), - to achieve business goals, - in realization of the business vision, - for the sustainment and enhancement of the business mission, - in response to strength, weakness, opportunity, and threat assessments, - in review of the enterprise value-chain, - of a global customer-base of all products/services. See http://one-world-is.com/rer/owis/emeif.htm. Without taking an enterprise "mission" view and tracking the mission's value-chain dynamics (especially in "Internet Time" pace of change), those laboring at the more-specific/tangible (e.g., hardware/software/data/metadata) levels of this business activity are working on "leaves, twigs, and branches" that have no direct-connection to the nourishment and "DNA instructions" (purpose) of their foundational "tree trunk and root structure" -- the globally-connected enterprise. This means these leaf, twig, and branch objects/activities are inevitably wasteful, fragmented, and impossible to integrate without redesign or replacement. The cost of the inevitable global/enterprise integration (i.e., mission-driven capability-defragmentation) to business and our overall well-being is huge (and probably enough to pay down several national debts in a year or so, and improve the quality of life of our entire species). (At the same time, this is what keeps many system/software developers and integrators in business, and is thus a dis-incentive for them to show or support their customers' more coherent unitary-tree of solutions and capabilities. On the plus of this fragmentation is competition-driven creativity and market economics.) See http://www.one-world-is.com/rer/owis/ue-gem/. Having said the above, I foresee that over the coming decade: - near-term enterprise-focused, mission-driven, strategically-managed informational capabilities, - incorporating the learned semantics of traditional EDI, existing MIS, and modeled processes, - probably leveraging the syntaxes of XML/XHTML, LDAP/DSML, SQL (Query and DDL), UML, WBEM, Java, and concordance-like searching and local/personal correlation (e.g., Wordnet http://www.cogsci.princeton.edu/~wn/) of lexicon and metadata, - over the medium of current and future "nets" will continue to grow in prominence, to the point that all major business (and individual/group/community/national/global) knowledge, requirements, and methods (semantics) will be captured, managed, applied, and maintained as a unitary-whole, without barriers, across a global value-chain. The result will be contextually relevant dynamic situational awareness/knowledge/wisdom for all those who are "connected", thus driving universal access as a mandate. There will be many who don't see this until well after it becomes available, and will thus put themselves (and stockholders/stakeholders) into a diminished future role (obsolesence, loss of market/mind share, etc.) to their customers. Roy (Nirvana? Or A Practical, More Capable, and Joyful World?) One World Information System 703-598-2351 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Rachel Foerster Sent: Tuesday, February 22, 2000 10:31 AM To: [EMAIL PROTECTED] Subject: RE: Article: Future of XML and EDI? Betty, I agree with and support your perspective and comments below -- except for one small suggestion. That is where you say that the data should be modeled. Before you can effectively model the data you must first model the business process and analyze the process information requirements. Then, and only then can you proceed to data modeling and object development. A small point, but a major issue. This is where traditional EDI and fallen on its sword...it's data-centric and not process-centric. That's why it's hit the brick wall. Rachel > > > > > Hi John: > > One of the biggest problems right now with XML/EDI is > everyone trying to write 'THE' standard. Large companies don't > know who is going to win. This is why you see most large > companies sitting on everyone of these consortiums. > > Large companies can afford the luxury of having > representation on every committee. The SME can't afford > this luxury. They are sitting back and are trying to > decide which way to go. > > My advice at the moment is for them to go ahead > and do XML. Create their DTD to match their business rules, > not an arbitrary standard. This will allow them the most > flexibilty. > > If you look at the catalog initiatives where they are > developing electronic catalogs. These initiatives don't > take any notice of the paper catalog. I read that 25% > of all IT budgets is used on creating catalogs. Paper > catalogs are not going away. The beauty of XML is that > you can accommodate all of the necessary products with > one DTD. However, if a company creates a DTD that matches > the way the author, maintain and process their catalog, > transforming that catalog data to the required standard > is a piece of cake. You can't take something like cXML and do > anything really useful with it IMHO. > > There isn't really a standard that 'fits all sizes'. > Every industry organization, TCIF, ATA, RIF, etc. have taken > X12 in and created their own standards for their industries. > I believe this is where EDI/XML standards should reside. > > If an organization writes a DTD to match their business, > then 'Father can't get thrown up the stairs with his hat on', > that is, unless Father has come home with too much to drink, > the 'Mother can throw Father up the stairs with his hat on' |-). > Remember XML is hierarchical so you have the opportunity before > Father goes up the stairs to (1) smell his breath; or (2) check > his pockets for money, etc. > > Really what I was trying to say in the slide about taking > advantage of EDI, is that there has been a lot of work put into > EDI. EDI messages are different than XML messages, yes. The same > intellectual analysis goes into doing EDI transactions than XML > transactions. The syntax is different and the logical structure > is different. However, the thought processes are the same. > > There are some factions who would like to just negate all > the work that has been done with EDI. This rationale is just > plain stupid IMHO. If we take advantage of what has already been > done and model the data appropriately, the XML curve is relatively > painless. I don't care how elegant your XML is, if it doesn't > match an organizations business process or is incomprehensible > to the average user, it isn't worth the digital signature on > the check. > > Betty > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > Betty Harvey | Phone: 301-540-8251 FAX: 4268 > Electronic Commerce Connection, Inc. | > 13017 Wisteria Drive, P.O. Box 333 | > Germantown, Md. 20874 | > [EMAIL PROTECTED] | Washington,DC SGML/XML > Users Grp > URL: http://www.eccnet.com | http://www.eccnet.com/xmlug/ > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/ > > > > > > I wish could have heard the accompanying words. In reading > the latter ones > > (eg: create a DTD for your business), I had the sense that > you would allow > > that the XEDI approach to translating XML to EDI is more > "transliteration" > > than translation. (That is, it can result in messages like > "Throw father up > > the stairs > > his hat.") Is this true? If not, what do you see as the > rationale for > > proceeding to take EDI <--> XML piecewise with a variety of > tailored DTDs, > > rather than using the underlying, EDI-complete dictionary > that (I understand > > that) > > the XEDI approach, or a similar approach using XSLT, does. > > > > Appreciate your insight into the full scope of the EDI - > XML opportunity. > > > > Thanks > > > > John Leary > > > > PS: How is it that your note came thru as "untranslatable" > > > > -----Original Message----- > > From: Betty L. Harvey [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, February 22, 2000 1:47 AM > > To: Scott Shulman > > Cc: Kanaskie, Kurt A (Kurt); [EMAIL PROTECTED]; > > [EMAIL PROTECTED] > > Subject: Re: Article: Future of XML and EDI? > > > > > > This message uses a character set that is not supported by > the Internet > > Service. To view the original message content, open the > attached message. > > If the text doesn't display correctly, save the attachment > to disk, and then > > open it using a viewer that can display the original character set. > > > > ==== copied out of NOTEPAD from the above message ==== > > > > XML will not replace traditional EDI, at least not in the > near future. > > The good news is that XML and can enhance traditional EDI. It can > > be the glue between the non-EDI enabled trading partners and the > > EDI training partners. > > > > I gave a presentation at XML99 that covered some of the issues > > of XML and EDI that I thought were important. If interested, > > it is available at http://207.168.47.3/papers/xml99/. > > > > I think it is important to use common sense when looking at > > the XML/EDI issue. As my Grandmother used to say 'Don't throw > > the baby out with the bath water!'. > > > > Betty > > > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ > > Betty Harvey | Phone: 301-540-8251 FAX: 4268 > > Electronic Commerce Connection, Inc. |=20 > > 13017 Wisteria Drive, P.O. Box 333 |=20 > > Germantown, Md. 20874 | > > [EMAIL PROTECTED] | Washington,DC > SGML/XML Users Grp > > URL: http://www.eccnet.com | http://www.eccnet.com/xmlug/ > > > /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ > /\\/\/ =20 > > > > > ========================================== > XML/EDI Group members-only discussion list > Homepage = http://www.xmledi.com > > Brought to you by: Online Technologies Corporation > Home of BizServe - www.bizserve.com > > TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]> > Leave the subject blank, and > In the body of the message, enter ONLY: unsubscribe > > Questions/requests should be sent to: [EMAIL PROTECTED] > To join the XML/EDI Group complete the form located at: > http://www.geocities.com/WallStreet/Floor/5815/mail1.htm > > ========================================== XML/EDI Group members-only discussion list Homepage = http://www.xmledi.com Brought to you by: Online Technologies Corporation Home of BizServe - www.bizserve.com TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]> Leave the subject blank, and In the body of the message, enter ONLY: unsubscribe Questions/requests should be sent to: [EMAIL PROTECTED] To join the XML/EDI Group complete the form located at: http://www.geocities.com/WallStreet/Floor/5815/mail1.htm ========================================== XML/EDI Group members-only discussion list Homepage = http://www.xmledi.com Brought to you by: Online Technologies Corporation Home of BizServe - www.bizserve.com TO UNSUBSCRIBE: Send email to <[EMAIL PROTECTED]> Leave the subject blank, and In the body of the message, enter ONLY: unsubscribe Questions/requests should be sent to: [EMAIL PROTECTED] To join the XML/EDI Group complete the form located at: http://www.geocities.com/WallStreet/Floor/5815/mail1.htm
