[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Syntax Free Models - was: [Fwd: Oracle Input for Core ComponentsWG]
Thanks Martin: Sorry you weren't there last week. The syntax you have described to me reminds me of a 'poor man's XML database'. I have known many companies who have been contracted to provide an XML database and use the file system as a physical database. It also looks a lot like the BSR. The BSR has the hierarchy in the name, i.e., ContractOrganizationName. The problem I see with this method is where do you show branching? I have to go back to my original questions. What is the goal? Who are we doing this for? If we are looking 10-15 years into the future when something else has replaced XML, then yes, maybe I can see this approach. However, in the IETM (Interactive Electronic Technical Manual) world, we always thought we would have holograms to represent the data by now |-). I have looked at X12 (I haven't looked at EDIFAC but I assume that they are similar). There is an implicit hierarchy in the X12 standards. The XML can fall directly from the EDI. I don't believe the hierarchy is difficult. The modeling isn't difficult. A lot of the hierarchy is just plain old common sense. Inventing yet another way to show the hierarchy will expend more time and energy than a lot of volunteers have. If we aren't going to model XML in XML, then there are lots of tools to available, UML, EXPRESS, IDEF, etc. There are a lot of manpower issues revolving around this effort. We have a diverse group with varied backgrounds coming together. This effort requires that: 1. XML professionals be trained and have an understanding of EDI. 2. EDI professionals be trained and have an understanding of XML. in addition 3. Training in whatever modeling methodology is selected. I am attaching a graphic that shows an XML model for 'goods' just as an example. Looking at X12, here are some of the areas that I believe are going to be difficult to come to agreement in XML: 1. When to use elements and when to use attributes. 2. Naming conventions 3. Implicit vs. explicit naming conventions. 4. Reuse components 5. Standard abbreviations Martin, you and I both know that 18 months isn't a very long time to get a consensus standard out the door, in fact it may be impossible. I have only seen it once with the railroad industry and we were only developing one DTD for a parts catalog. This effort is much broader than a single DTD. This issue needs to be resolved before we can move on. In "Field of Dreams" the voice said "If you build it, they will come". That may be true for baseball fields but if we don't "build it" for the common business, they will not come. I was told about the first commercial that mentioned XML last week while in Orlando. I finally saw the commercial last evening. The Microsoft commercial revolved around understanding eBusiness and XML. Either we do this in Internet time or we don't do it at all. Betty /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Betty Harvey | Phone: 301-540-8251 FAX: 4268 Electronic Commerce Connection, Inc. | 13017 Wisteria Drive, P.O. Box 333 | Germantown, Md. 20874 | harvey@eccnet.com | Washington,DC SGML/XML Users Grp URL: http://www.eccnet.com | http://www.eccnet.com/xmlug/ /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/ On Sun, 6 Feb 2000, Martin Bryan wrote: > Betty > > > > I went back and looked at my notes and I have two different terminologies > > being used "syntax free modeling" and "syntax neutral approach". I am > > confused about how you can do either and create consistant and usable XML > > but I want to hold off judgement until I get a definitive answer what > > "syntax neutral approach" really means. > > My take on this when I was talking to Bob Glushko the week prior to the > ebXML meeting was that we did not want to express semantics in terms of XML > DTDs, XML Schemas or XML-Data specs. What you want is something that is > neutral to all of these but that still expresses the hierarchical > relationships required to model data and processes to be used within an XML > environment. One of the things that I suggested is that XML Paths provide > you with a neutral description of hierarchical relationships which are also > relevant to things like links, transformations, etc. > > So you say Order/Item/Quantity[Units="Kilograms"] or something along those > lines, which is a syntax neutral way of describing a component of a > hierarchy. > > If you use this within a Manufacturing environment rather than an Purchasing > one you can add a process qualifier at the front, e.g. > Manuafacturing/Order/Item/Quantity[Units="Kilograms"] rather than > Purchasing/Order/Item/Quantity[Units="Kilograms"] > > > Here is my major concern. In SGML world there was a lot of theoretical > > ideas that caused consumers eyes to glaze over. I am seeing the same > > thing happening in various sectors of the 'new' XML world. SGML would > > have been adopted much more widely if it was it wasn't presented to the > > potential users in a way that it was understandable instead of esoteric > > terms. I just hope we aren't repeating history here. > > Its not just history we need to avoid repeating: we also have a whole host > of parallel "modelling" techniques, such as UML, BSI, BSR,..... that somehow > have to be kept in view. > > Martin Bryan >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC