Re: [ubl-dev] looking for practical examples

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2009-02-10 19:00 +0100, Alexander Whillas wrote:
>2009/2/10 G. Ken Holman <gkholman@cranesoftwrights.com>:
> > Alex, you originally asked for a Catalogue document, but I had to concoct
> > bogus information to complete the requirements such as provider and
> > receiver.
>
>Yes, the provider/receiver example was out of context for my
>requirements as is distoring the <MinimumOrderQuantity> to fit the
>inventory level (althought this would be functioanlly equivalent in my
>situation).
>
>I originally thought Catalogue was what I was after as this it what
>its called in the rag-trade and in the online shop. It does cover 95%
>of what I need it to do.

But you are shoehorning your requirements into something that could, 
very well, have a legitimate representation in the future when you 
really do need a catalogue.

> >> On the other hand I do have sympathy for Ken's proposal that basing the
> >> business object on XML conforming to the UBL schema will add some value.
>
>The main value would be that the 2 seperate software systems i.e.
>OpenSource online shop and a proprietary inventory management system
>could be independently replaced by another system if that other system
>spoke UBL.

True.

> > Perhaps you need something like:
> >
> > <?xml version="1.0" encoding="UTF-8"?>
> > <Inventory xmlns:cbc=
> > "urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
> >           xmlns:cac=
> > "urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
> >           xmlns="urn:x-Whillas:Inventory">
> >  <cbc:IssueDate>2009-02-10</cbc:IssueDate>
> >  <cac:InventoryItem>
> > ...
> >  </cac:InventoryItem>
> > </Inventory>
>
>I was rather hoping not to have to write my own document schema, which
>gave birth to my hunt for an existing standard after reading this:
>http://www.tbray.org/ongoing/When/200x/2006/01/08/No-New-XML-Languages

Ah, but it is a very fine line.  And Tim even mentions UBL on that 
page, though he doesn't cite re-use.

The UBL Common Library was designed for re-use by the UBL TC for all 
of the UBL documents ... the UBL TC is a user of the library just as 
anyone else could be a user of the library.

You could even choose to submit an Inventory document, built on the 
UBL Common Library, to the UBL TC for consideration for including in 
future versions of UBL: 2.1, 2.2, 2.x.  That isn't to say the UBL TC 
will automatically accept any and every new document sent its way by 
anyone and everyone.  But, for example for 2.1, a number of groups 
are forwarding well-thought-out and detailed proposals for new UBL 
business objects and new UBL documents using existing and new 
business objects.  We may very well double the number of UBL documents in 2.1.

Tim Bray's admonishments are wise, but what I don't see on that page 
are warnings about using square pegs in round holes, or about 
shoehorning something that doesn't quite fit to make things 
uncomfortable to use.

I see the design of UBL as a balance between re-use and new 
development:  the committee started with a set of 31 documents and 
may have 60 or 70 in UBL 2.1, and who knows how many in UBL 
2.x?  Throughout all of these, the existing UBL business objects will 
persist, and more will be added to the library.  We don't purport to 
have solved everyone's problems, but we believe we've created a 
platform on which everyone can solve their problems.

>I'll also be sending him Order information for fulfilment.

Okay ... more documents will be explored by you in the future ... 
that's fine and UBL can help with some of them ... but I'm guessing 
an inventory record is different than a catalogue, unless the 
catalogue *always* contains *all* items in inventory.  And if you are 
going to publish catalogues in the future that are not expressing 
everything found in inventory, then either dream up an unambiguous 
strategy for using the catalogue documents in proper contexts or 
create a new document.

>He'll send
>me regular inventory updates as well as new Catalogue items to sell.

Oh, so there *are* provider and receiver parties!  Perhaps after all 
this discussion the catalogue will satisfy you, but only you can assess that.

And if you can join the TC, bring in your new documents, and find 
others to collaborate with in order to come up with flexible and 
useful configurations of those new documents, they might end up 
becoming UBL documents!

I hope this helps.

. . . . . . . . . . . . Ken

--
Upcoming hands-on XSLT, UBL & code list hands-on training classes:
Brussels, BE 2009-03;  Prague, CZ 2009-03, http://www.xmlprague.cz
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal