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] Tools for database support for UBL?


Steve,

With the jCAM Java to look at someone can easily write
a Python port by inspecting the source code....

pCAM anyone?

Cheers, DW

----- Original Message ----- 
From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
To: <ubl-dev@lists.oasis-open.org>
Sent: Monday, December 20, 2004 10:23 AM
Subject: Re: [ubl-dev] Tools for database support for UBL?


David

Many thanks. This is looking better and better. We're still just with
Java though - I'd be keen to see the first such tools in C++, .NET or
XSLT, or perhaps something like Chee-Kai's UBLish script for XPS
(Not that I've anything against Java of course, just that
I find I have to use other means most of the time)

Steve

>>> "David RR Webber" <david@drrw.info> 20/12/04 15:13:45 >>>
Steve,

Good thoughts.   It was exactly this kinda of use case that
you describe that we have the CAM <ExternalMapping>
mechanism for.

As you note - since all the tough work has been done on the
CAM side - its an easy extension to add this functionality
to cope with morphing XML input into database columns.

Basically you already have the CAM <structure> section
where you specify the inbound UBL instance layout - then
in the <ExternalMapping> section you specify one or more
SL tables - and then use XPath expressions to move from
A to B.  The gnarly bit is handling loop constructs and
conditionals - and that's covered in the grouping constructs
the <ExternalMapping> section provides and the context
business rules in CAM.

Since the jCAM open source processor is available - upgrading
that code base to handle what you have in mind is a weeks worth
of effort I'd estimate.  http://www.jcam.org.uk

Then of course there is the reverse.... outbounding XML from
the SQL tables - I'd estimate another week to get that running
once you have the inbounding done.

Enjoy, DW

===========================================

----- Original Message ----- 
From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
To: <ubl-dev@lists.oasis-open.org>
Sent: Monday, December 20, 2004 8:41 AM
Subject: Re: [ubl-dev] Tools for database support for UBL?


David

I'd actually been thinking slightly differently to this:

I had it in mind that before any integration, mapping or processing to a
backoffice
system one might wish to store the incoming UBL or UBL-like document(s) in a
special database whose tables were designed specifically for the Schema(s)
used
and then to use the data from this database for the processing into the
target
application(s). The document instance would probably be stored as a whole
too
in order to provide the audit log/trail and integration with any document
management
and/or archiving systems. Having a tool to easily create database schemas
from UBL
based XSD Schemas and likewise to create corresponding update SQL statements
from
the incoming document instances might greatly simplify the downstream
processing
(either using J2EE/EJBs based on the tables or the equivalent in C++, .NET
or scripts).

It sounds like the HyperJAXB API is just the sort of thing, especially as it
uses
Hibernate to cater for various databases.

However, it would interest me if there were tools other than those based
around
the Java/J2EE technology, e.g. ones which would work with .NET or scripting
languages or particularly any using standards such as XSLT. If none were
available
then I'd be keen to see something developed, say as opensource :-)

Of course it has been very interesting to find out more about what is out
there now
to provide alternatives to this architecture. I'd imagine manipulating data
once it is
persisted in a database might be less challenging for implementers than
manipulating
it just as XML, e.g. through classes and/or stylesheets alone.

I wouldn't see a sufficient business case for spending vast amounts of money
on this
though.

I could imagine the case for basing such tools on CAM mapping to achieve the
above.
Thanks.

Just feeling my way here :-)

All the best

Steve

>>> "David RR Webber" <david@drrw.info> 16/12/04 17:03:24 >>>
Stephen,

I just re-read your note and realized another item here:

>>>>>>>>
 1. What sort of tables could UBL map to? What would be the relational
mapping, say?

2. Need to map Schemas to 'CREATE' SQL and develop a generator for that

3. Need to map instances to 'UPDATE' SQL (etc ...?) and develop a generator
for that
<<<<<<<<

CAM templates include the optional <ExternalMapping> section explicitly to
support this round-tripping to / from SQL tables between partner
applications.

You'd have to target some popular accounting applications with this
technique
and denote their tables and columns.

The jCAM when used with Hermes then becomes an instant integration
plug-in to popular accounting suites.

Enjoy, DW

----- Original Message ----- 
From: "Stephen Green" <stephen_green@bristol-city.gov.uk>
To: ">" <"'ubl-dev@lists.oasis-open.org'"<ubl-dev@lists.oasis-open.org>
Sent: Thursday, December 16, 2004 5:30 AM
Subject: [ubl-dev] Tools for database support for UBL?


Dear UBL-DEV, Hi

If anyone has interest in the possibility of developing tools to help store
UBL
and UBL-based instances in a relational database I've been thinking along
the
following lines:

1. What sort of tables could UBL map to? What would be the relational
mapping, say?

2. Need to map Schemas to 'CREATE' SQL and develop a generator for that

3. Need to map instances to 'UPDATE' SQL (etc ...?) and develop a generator
for that

I wonder if any have thoughts of devloping something like the above, perhaps
as opensource
or priced attractively to foster wider UBL / UBL-like Schema adoption (the
key to successful
use of UBL perhaps).

What worries me is the complexity of UBL but there's the challenge and the
drive I suppose.
It would seem obvious to just treat every ABIE as a table and every document
as an
ABIE/table too. The relationships are where I get a bit lost.

Another key factor would be to make the tools generic - to handle any
Schemas built
by the UBL NDR rules and from the UBL spreadsheets (e.g. see UBLish from
softml.com
which uses a scripting language similar to perl).

All the best

Steve









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