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] looking for practical examples

OK, so a document/message is needed. Although I would expect the
Catalogue could meet 90% of the requirement, you have a choice:

1. Create a new document called, say, Inventory - with your own
namespace for the document but import the common schemas so
you can make it almost the same as the UBL Catalogue - just with
a new InventoryLine, like Ken says, which adds StockQuantity or
something like that (and maybe a few more things like that). There
are a few things to make the writing of the schema (like Ken, I too
strongly recommend keeping to a schema - testing the messages
that they are valid by the schema - at design stage at least). You
will want the extra InventoryLine and somewhere to put it in the set
of schemas. Maybe Ken has an opinion on whether to put this
aggregate in the document schema (I guess that breaks the NDR,
Ken) or whether to create not just a custom document schema but
a 'common' schema too: If the latter then maybe both a basic and
an aggregates common schema? Those technical issues might
seem overly detailed. We could probably easily create a set of
schemas for you if you choose this route. Or maybe creating your
own you'd have the control you might need over changes to them
with time. Eventually it might warrant standardisation - perhaps in
a future UBL minor release. No promises there of course. Maybe that
is what the pair of systems need though so they can claim UBL
conformance in future versions (if that helps marketing and the
users' business requirements, say).

2. Maybe the alternative seems more attractive which is what Ken
mentioned as use of the UBL extension point (in every UBL document
- if the subset used permits). This involves two potential challenges,
as far as I know: a) writing the extension and specifying it with a
schema and b) deciding which, if any, subset of Catalogue to use and
whether to create your won subset and specify it yourself in some way.
A way of specifying anything which you can't write a schema for is
to use some kind of set of assertions: say with Schematron if not too
complex or, my hobby horse, with test assertions (I can send a link
to a fairly decent schema design for writing these in XML if you like).

All this is fairly standard stuff so it should be quite future-proof for your
applications (regarding changes, skill sets, etc in future). You might
have a bit of prose spec writing to do though besides just a set of
schemas to pack together and/or write and send to the 'Cobol' guy(s).

All the best

- Steve

2009/2/10 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org

Stephen D. Green

Document Engineering Services Ltd

http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice

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