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


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-architecture message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: OTA Tag name rules

And this comment comes from the person who states a straight-forward
approach????   The

I see a need for speed - get the tag, vector to the process in one step.
Any additional effort to this will make the system unstable and very slow.

The question is resolution, what level are the logical units that we want to
roll as we derive from core components.  OTA versioned every "segment" which
is wrong, and a move on some member(s) parts to make the system ugly to
force a move to XML Schema from DTDs.  I hope determining the resolution
level of these logical units and when to roll them are what BP & CC is
including in their definition work.

Yes, we have major disagreement on all this.  And yes I understand the
tradeoff on what we are giving up as well.

- Bruce

----- Original Message -----
From: "David RR Webber" <Gnosis_@compuserve.com>
To: "Bruce Peat" <BPeat@eProcessSolutions.com>
Cc: "Christopher Ferris" <chris.ferris@east.sun.com>;
Sent: Saturday, September 30, 2000 12:34 AM
Subject: Re: OTA Tag name rules

Message text written by Bruce Peat

For speed reasons the version should be part of the tag - but only at the
logical unit level where we want to maintain version control.

Version should be for noun (core components) and verbs (business process).

- Bruce


I have to major disagree on all this.

W3C Schema has versioning mechanisms now (they are implicit
not explicit) - but that is what we should be looking at - and NOT
inventing some artificial another layer here that will quickly
become unmanageable.

In the GUIDE approach I pragmatically used the namespace
level to point to the version, and this then gives you groups
of related items at a particular level.  Now you could namespace
an individual item of course, but notice this mechanism is not
ADDING a version attribute to the tag itself - which just means
pure overhead.

Also - when you are using the GUID as an attribute to point to
an element level definition - and there are major reasons for
doing this when you look at the RegRep mechanisms that
support this - then you get another level of richness - and
the ability with RegRep itself to version and sub-class,
and so on.  THAT I believe is where you should be focusing
on providing versioning - and most particularly tying this to
trading partner profiles (I know my TP has SAP V. that
needs this, not that).  This then gets rid of dumb version
numbers and replaces them with a smart mechanism based
on business use that uses the mechanism inside the RegRep
to empower this.

So - I'm VERY unhappy with any thoughts of trying to tie
things into tags with version attributes.

Did I scream 'Aaarrrghhh - NO!' loud enough here?

Thanks, DW.

[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