[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>; <ebxml-architecture@lists.ebxml.org> Sent: Saturday, September 30, 2000 12:34 AM Subject: Re: OTA Tag name rules Message text written by Bruce Peat > IMHO - 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 <<<<<<<<<<<<< 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.10.1.5.1 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]
Powered by eList eXpress LLC