OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[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 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]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC