Re: [ubl-dev] Tools for database support for UBL?

["David RR Webber" <david@drrw.info>]

Adrian,

CAM is definately swimming as part of this same pond.

Rather than exposing SQL though, the idea would be to output
CAM templates from the models as XML.

I've already explored this for XSD schema models direct to CAM templates
using VisualScript as the tool.

Using SQL is a bit 1980's really here - although I suspect a healthy mix
of XML and SQL here - where the SQL is represented in XML
syntax constructs - is more 2005-ish - and then using XPath for the rules.

One feels we are sat on some giant rolling wheel of course - and that
its just turning thru another rotation here!

Nice links.

Cheers, DW

----- Original Message ----- 
From: "Adrian Walker" <adrianw@snet.net>
To: "Stephen Green" <stephen_green@bristol-city.gov.uk>
Cc: <ubl-dev@lists.oasis-open.org>; <groups@essentialstrategies.com>
Sent: Monday, December 20, 2004 2:52 PM
Subject: Re: [ubl-dev] Tools for database support for UBL?


> David, Stephen --
>
> It's somewhat tangential to your discussion, but as background, you may
> like to look at an approach where you would translate your UBL model into
> business rules in executable English, and into tables of metadata.
>
> Once the translation is done, the SQL Create statements can be generated
> automatically, and one can reason automatically about the metadata, and
> also about sample real data, to debug specs of the applications.
>
> A possible accounting model is at the first link below.  Does anyone have
a
> model like that in UBL please?
>
> The business rules idea is explored in depth at the further links below.
>
> How does is sound?             Cheers,  -- Adrian
>
> http://www.tdan.com/i030ht01.htm
>
>
http://www.reengineeringllc.com/A_Browser_Environment_for_Business_Rules_Over_SQL_2_Rev1.pdf
>
> http://www.reengineeringllc.com/Internet_Business_Logic_Presentation.pdf
>
> http://www.reengineeringllc.com/demo_agents/DataDictionary1.agent
>
> http://www.reengineeringllc.com/demo_agents/DataAssurance1.agent
>
> http://www.reengineeringllc.com/demo_agents/NetworkedSQL1.agent
>
> Dr. Adrian Walker
> Reengineering LLC
> PO Box 1412
> Bristol
> CT 06011-1412 USA
>
> Phone: USA 860 583 9677
> Cell:    USA  860 830 2085
> Fax:    USA  860 314 1029
>
> At 01:41 PM 12/20/2004 +0000, you wrote:
> >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
>
>
>