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] UBL and a functional SQL schema


> HyperUBL is thorough, I agree. However, it's no problem to compile 
> only parts of the UBL schemas, I think.

Yep.

> ld you tell more about "tables to store fixed lists"? This could be a 
> point for optimization.

I think but am not sure that you are creating tables for lots of little 
things in the UBL schema that are defined as fixed lists of values.

I don't have the time at this moment to find a concrete example, so 
I'll provide a fake one: If you had:

<orderDeliveryShippingVendor>UPS</orderDeliveryShippingVendor>
where the value can be..

UPS
USPS
FedEx
DHL
Airborne

etc...

you could either:

create table orderDeliveryShippingVendorType
	id bigint notnull
	name varchar

etc.

and store an fKey to the orderDeliveryShippingVendorType from the 
master order table..

or you could just have in the documentation that 
orderDeliveryShippingVendor can be one of UPS, USPS, FedEx, DHL, or 
Airborne and put a little enumeration in the schema definition:

create table MasterOrder
	... etc etc...
	orderDeliveryShippingVendor ENUM('UPS, USPS, FedEx, DHL, Airborne')

so right there you have done two things:

	-exposed a "fixed list" spec from UBL in the schema which acts as 
self-documentation
	-eliminated an fKey and a whole other table!

hope that's intelligible.

> That's actually what I'm interested in. Taking the size of UBL into an 
> account, it might be easier to tune the auto-generation process than 
> develop the schema manually. So if you would have time to point out 
> the anomalities, I will do my best to correct them.

You may well be right. It would BY FAR be better for me were you to 
immediately break up the massive schema file into separate schema files 
for each 'component' in the UBL spec.

Than tuning the process would help even more, because improvements 
could be made in specific domains (order, invoice, etc)

> I'm realy grateful for your critics, since it's constructive. I'll try 
> to overthink few things in HyperJAXB and HyperUBL. Could I maybe ping 
> you in a couple of weeks asking to check out the new HyperUBL schema?

Of course!

_a


-- 
alex black, founder
the turing studio, inc.

510.666.0074
root@turingstudio.com
http://www.turingstudio.com

2600 10th street, suite 635
berkeley, ca 94710




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