Re: [ubl-dev] looking for practical examples

[Stephen Green <stephengreenubl@gmail.com>]

Good, solid arguments on the XML side of things, as always, from Ken.

I'm not completely convinced though that UBL is the ideal tool for the
job in hand with this stock tracking system. I do agree with Ken that the
use of UBL lends itself to business objects internal in a system but I kind
of favour others' opinions too that UBL is not designed for business objects
like that. It isn't a database schema but a message/document schema -
in fact its purpose might be considered to be more legal than technical.
I'd just caution a little wariness in using UBL to design a schema for the
internal use of a system: Maybe it will help, if you have to create a UBL
document from that same schema, if the internal system uses classes or
tables or the like (business objects) based on UBL structures but I remember
Tim McGrath emphasising that it is not normalised for this purpose. So it
might be that the issue about whether conformance to the UBL schema is
beneficial enough for the cost of implementation is only disputable here
because the aim is not to produce a UBL document but an internal business
object. In fact, to make a business object for stock tracking the only major
value you might glean from UBL's Catalogue document might be to list the
possible ingredients of the business object, with little if anything at all to
be gained from basing the business object structure on the UBL structure.

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.
I just think that that value might not be so obvious or so great when no actual
document output or input is immediately envisiaged (at this stage). The
compromise which is most obvious here is to give latitude in the creation of
the business objects (i.e. allow practical database or class structure design
issues to take priority over UBL schema conformance/validity when creating
the business objects, database tables, etc) in such a way that documents
conforming to UBL can still be created by transformation later if necessary.
This would just mean making provision for the list of things and cardinalities
of things in the UBL Catalogue, like one SKU per Item type and many Item
Instances per Item and so on. Pretty obvious for the most part. I would tend
to think there isn't much danger of creating a set of business objects which
wouldn't support creation of a UBL Catalogue from them if ever necessary.
So UBL just provides an entry-level indicator that you have thought of all the
bits and pieces the tracker needs. Following this line of thought leads to the
conclusion that regarding the quantity in stock, there may be no value in
following the UBL extension mechanism to add such items: Just put them
where seems obvious in the business objects and remove them if there is
ever the need to create a UBL 2.0 Catalogue document.

Maybe this is missing the pointt somewhat though. If so I do apologise.

All the best

- Steve

2009/2/10 G. Ken Holman <gkholman@cranesoftwrights.com>:
> At 2009-02-10 11:15 +0100, Alexander Whillas wrote:
>>
>> The SKU is American in origin and since most/popular eCommerce system
>> online (at the moment) originate in the USA this has sort of become
>> the "de facto standard", but as its just an identify and has no fixed
>> formatting constraints it doesn't really matter what you call it. What
>> I'm really interested in is using it for stock tracking.
>
> That tells me you could be treating it as a <CatalogueItemIdentification>
> semantic (if you are basing your identification on the catalogue you are
> creating), but I like Steven's idea of using <StandardItemIdentification>
> and in the <ID> child indicate in the meta data that it is an SKU.
>
>> For stock tracking I need to keep a record for every combination of a
>> products attributes (size, colour etc) or AdditionalItemProperty as
>> UBL calls them.
>
> Then I'll retract what I said earlier and move the property attributes "up"
> in the document model to <Item> instead of <ItemInstance>.
>
>> Thus I need an ID at the ItemInstance level and UBL
>> seems to only have one identifier at that level: SerialID. Is this
>> correct?
>
> No, SerialID is for a particular *instance* of a particular item.  As I
> understand what others have said in the past, if you are tracking the
> properties of an item *in general* (i.e. all instances of that item), then
> you use properties of <Item>.
>
> For example, if I had three Gizmos, all in red, I would use the following
> (which validates against the UBL Catalogue schema) to describe a catalogue
> line for red Gizmos and the three that I had in stock with unique serial
> numbers:
>
> T:\ftemp>type whillas.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <Catalogue xmlns:cbc=
> "urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
>           xmlns:cac=
> "urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
>           xmlns="urn:oasis:names:specification:ubl:schema:xsd:Catalogue-2">
>  <cbc:ID>1</cbc:ID>
>  <cbc:IssueDate>2009-02-10</cbc:IssueDate>
>  <cac:ProviderParty>
>    <cac:PartyName><cbc:Name>Me</cbc:Name></cac:PartyName>
>  </cac:ProviderParty>
>  <cac:ReceiverParty>
>    <cac:PartyName><cbc:Name>You</cbc:Name></cac:PartyName>
>  </cac:ReceiverParty>
>  <cac:CatalogueLine>
>    <cbc:ID>A</cbc:ID>
>    <cac:Item>
>      <cbc:Description>Gizmo</cbc:Description>
>      <cac:StandardItemIdentification>
>        <cbc:ID schemeURI="urn:x-SKU">ABC987</cbc:ID>
>      </cac:StandardItemIdentification>
>      <cac:AdditionalItemProperty>
>        <cbc:Name>Colour</cbc:Name>
>        <cbc:Value>Red</cbc:Value>
>      </cac:AdditionalItemProperty>
>      <cac:ItemInstance>
>        <cbc:SerialID>123</cbc:SerialID>
>      </cac:ItemInstance>
>      <cac:ItemInstance>
>        <cbc:SerialID>124</cbc:SerialID>
>      </cac:ItemInstance>
>      <cac:ItemInstance>
>        <cbc:SerialID>125</cbc:SerialID>
>      </cac:ItemInstance>
>    </cac:Item>
>  </cac:CatalogueLine>
> </Catalogue>
> T:\ftemp>w3cschema-all
> u:\cd\artefacts\os-UBL-2.0\xsd\maindoc\UBL-Catalogue-2.0.xsd whillas.xml
> Xerces...
> No validation errors.
> Saxon...
> No validation errors.
> Altova...
> The XML data is valid
>
> T:\ftemp>
>
>> I'll also need to record a stock level for each instance. There
>> doesn't seem to be anything I can use for this that the ItemInstance
>> level except, again AdditionalItemProperty?
>
> Here I'm thinking you might use an extension, since as I understand it, the
> semantics of a Catalogue are not really the semantics of an inventory
> record.  I don't see anything jump out at me.
>
> How about overloading the <cbc:MaximumOrderQuantity> concept to be your
> stock level?  Or do you otherwise already have limits on order quantities?
>
> Perhaps someone on the list can recommend an appropriate item to use for
> this semantic.
>
>> I put in the name spaces so you might correct me as to what I'll need
>> there :) I'm on a Mac and the only tool I seem to have been able to
>> find is Exchanger XML Lite (www.freexmleditor.com) which I think does
>> some basic validation but I haven't explored how helpful it is if you
>> give it a .xsd it doesn't know (it does have a UBL 1.0 example
>> however). Advice on a better editor for Mac would be most welcome.
>
> I use emacs.  :{)}  Not everyone will agree with that.
>
>> The mandatory fields might be a problem as they seem to imply the
>> other documents, which in turn implys the whole UBL (or is ebXML?)
>> process.
>
> It doesn't imply process, it only implies document model requirements.  The
> Catalogue is being sent from a provider to a receiver.
>
>> At this stage I was just looking for a standards way to
>> represent the products catalogue (half for stock tracking purposes)
>> between two systems. The UBL process does seem sensible but I'm only
>> responsable for one communication in the chain and so the rest of
>> parts are not applicable or beyond my scope and/or control.
>
> Sure, but by using UBL, when it comes time to address other aspects of
> scope, you will have built a foundation on a common library of business
> objects across multiple document models.
>
> And UBL is designed such that you can add your own document descriptions on
> top of the common library.  I cover this in my hands-on UBL class.
>
>> I guess I plan to take only the parts I need and try and comply as
>> much as possible, within the time constraints of my project.
>
> Yes, UBL is there to take off the shelf and only use what you need.  The
> benefit is that you are building on a suite of business objects that can be
> used in multiple document exchanges.
>
>> Its a PHP
>> project and so I really only have to aim for well formed XML not so
>> much adherence to a strict schema. I guess this is how standards
>> evolve, hand-to-hand with industry/necessity. If UBL becomes adapted
>> by other OS platforms, more than my implementation, then I guess
>> stricter compliance will follow.
>
> I highly recommend that you stick with conformance and not just
> well-formedness ... though I admit it adds a small amount of extra work to
> start.
>
>> The 'ActualDeliveryDate' example is interesting as ActualDeliveryDate
>> would be a process/time dependant variable which only comes into
>> existence once the Order has actually been delivered. While the goods
>> are in the process of being delivered, they still need and Order with
>> a Delivery type.
>
> Looking at our Crane-UBL2Report-Catalogue-EN.html report for all of the
> information items used in Catalogue, I do not see that ActualDeliveryDate is
> used anywhere at all in that document type.
>
> This implies to me that you'll have other document types, such as Order.
>
> Which strengthens my argument to use the UBL business objects in the common
> library and UBL documents on top of that common library to ensure the
> expression of information found in multiple documents is the same.
>
> 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