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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-dev message

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


Subject: RE: [ubl-dev] Customising and versioning


Marc, 

Interesting comments - and reflects typical practice.  I'm deep in these
trenches - and the "no added value" is a loud bell here!
 
I've been working the past few weeks on automated regression testing
tools using CAM and XML to attempt to reduce significantly that cycle
cost. 
  
The idea is this - you take a "happy path" XML transaction - then run it
through a batch process using CAM template and a bunch of xslt scripts
with includes of variables that CAM then runs - and generate lots of
deltas of the happy path to test all the variences in the data stream
that you need.  By using the CAM template and xslt in tandem you can
prune and extend the content very flexibly using dynamic parameters and
batch scripts. 
  
Obviously as you note - for large transactions and complex processes -
this is non-trivial to setup. The transactions are then submitted as a
batch to our test environment server using our S2S Hermes client setup.
  
On the backend we then run an Oracle extract XML utility to dump each
transaction out of the database into an XML log - including any
validation warnings or errors.  Finally we use an xmldiff command line
tool - to compare the XML logs with the original XML logs from the
prior runs.

I'll post some sample CAM, xml and xslt to the CAM TC docs' list later
today and send out the link for those that are interested in these test
data generation techniques. 
  
Cheers, DW 

-------- Original Message --------
Subject: RE: [ubl-dev] Customising and versioning
From: "Marc de Graauw" <marc@marcdegraauw.com>
Date: Tue, September 12, 2006 8:19 am
To: <ubl-dev@lists.oasis-open.org>

Fraser Goffin:

| Personally I wouldn't change a namespace for a minor revision. A
| namespace change is a 'breaking' change and means that implementers
| end up having to either a) upgrade their processing logic, and/or b)
| support multiple concurrent versions which have much greater churn.

+1 on this one.

A common scenario for a minor release is added functionality which not
every
exchange partner uses. We once proposed changing namespaces for minor
versions, but this means exchange partners which do not use the added
stuff
need to use new schemas. And this requires testing the interfaces again.
I
don't think it is realistic (unless you can force them) to expect
exchange
partners to test their interfaces when there is no added value at all
for
them. In principle those tests could be simple and mostly automated, in
practice in larger organizations tests are not automated and testing a
set
of interfaces is a big and expensive job.

Marc


---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org 



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