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]

> 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

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

> 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