[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] looking for practical examples
Just to clarify: when I wrote that a document has to contain things sometimes because it shares a particular type with other documents I didn't mean the document instance has to contain those things. It just means that it might be that without any subsetting there is the *potential* for a document to contain something irrelevant because other documents need that thing. One aim of defining subsets is to eliminate such irrelevant elements from appearing in document instances where possible. This gets rid of a lot of the 'bloat'. An Order, say, does not need an ActualDeliveryDate but it does need a Delivery type and that happens to contain ActualDeliveryDate because Delivery is also used in documents like Invoice which do need it. A subset choice would be to only support ActualDeliveryDate in the Invoice and not in the Order but that has to be specified as a custom requirement since it is not specified by the standard schema set. That's why the documents look so complex when they needn't (IMO). I think you clearly have sense to only aim to support those bits of a Catalogue which make sense and leave out all the masses of other things. There might be a challenge (and there might not if you are lucky) about how to ensure interoperability with other implementations of Catalogue, if you need to do so. Really those bits of Catalogue you include in your example are (and ideally should be) those same bits various subsets of the Catalogue also include. To formalize this is the problem subsetters/customizers grapple with. Hence NES, OIOUBL and SystML1/SystML2 (also UBL 1.0 SBS). - Steve 2009/2/9 Stephen Green <stephengreenubl@gmail.com>: > I'm no expert but I think the SKU identifies products whereas > the serial ID is to identify an instance of a product. I would > likely use SellersItemIdentification/ID initially which could be > some ID other than a SKU but could be a SKU if that is what > the seller uses. You could also include something more > specific to an SKU to leave the seller free to use their own > product ID in addition to a SKU if they prefer. As far as I know > the humble SKU isn't universally adopted outside the USA. > Other alternatives seem to be GTIN (in UK, for example), > APN (in Australia), EAN (in Europe and elsewhere) and UPC. > How about using the StandardItemIdentification for the SKU > or EAN? The definition in the schema is > "Associates the item with its identification according to a standard system." > http://docs.oasis-open.org/ubl/os-UBL-2.0/xsd/common/UBL-CommonAggregateComponents-2.0.xsd > Anything related to the 'class' of the item is found in cac:Item > and anything related to the actual instance of an item is in > cac:ItemInstance (not appropriate for a catalogue unless it is > an item like something unique on eBay, say the original James > Bond underwater Lotus Esprit, presuming there was just one). > ItemInstance contains things like RFIDs and Lot Numbers, as > well as SerialID. These are appropriate for a Despatch Advice, > say. [IMO unfortunately] the sharing of common types means > other documents tend to have to support them too. To see what > a given document type potentially contains easily, I tend to find > it useful to generate an XML example from the document schema > using, say, a tool like Liquid XML or XML Spy (and there are tools > more specific to e-commerce standards like UBL). > > By the way, your XML will need other namespaces from UBL as > it needs to prefix things like Item (usually as cac:Item) and like > ID (usually cbc:ID) - but I guess you were leaving those things > out to save time creating a real UBL example. Generating an > example with a decent tool should include all those extra things > like the other namespaces and prefixes and any mandatory fields > and quite improtantly the mandatory values in some of the coded > items (not so many of those in a Catalogue, fortunately). > > Otherwise you've got the right idea with the Catalogue I think. It > is one of the UBL documents which could be very complex but only > actually needs to be quite simple in many cases e.g. when used > as a simple price list). If the catalogue has to be stored in a database > then it might be you only want to do updates on individual lines from > time to time - hence the Catalogue line update document type, etc. > Otherwise you might have to replace the whole cataalogue every > time there is a change. > > All the best > > - Steve > > > > > > 2009/2/9 Alexander Whillas <whillas@gmail.com>: >> OK, >> >> Thanks for the help guys. I'm going to look though all the reference >> material you've mentioned here and see if I can't produce a draft for >> my own customization of the schema. I found the >> UBL-CommonLibrary-2.0.xls file, in the official spec's, very helpful >> (once I realised what it was). Filtering by 'Object Class' has helped >> to build a picture of the whole hierarchy. >> >> So basiclly, if I want to represent a complete Catalogue of products I >> have use the Catalogue Document which will look something like this: >> >> <?xml version="1.0" encoding="UTF-8"?> >> <Catalogue xmlns="urn:oasis:names:specification:ubl:schema:xsd:Catalogue-2"> >> <CatalogueLine> >> <ID>ABC001</ID> >> <Item> >> <Description>Shirt</Description> >> <ItemInstance> >> <SerialID>ABC001-SML-BLUE</SerialID> >> <AdditionalItemProperty> >> <Name>Size</Name> >> <Value>Small</Value> >> </AdditionalItemProperty> >> <AdditionalItemProperty> >> <Name>Colour</Name> >> <Value>Blue</Value> >> </AdditionalItemProperty> >> </ItemInstance> >> <ItemInstance> >> <SerialID>ABC001-LRG-BLUE</SerialID> >> <AdditionalItemProperty> >> <Name>Size</Name> >> <Value>Large</Value> >> </AdditionalItemProperty> >> <AdditionalItemProperty> >> <Name>Colour</Name> >> <Value>Blue</Value> >> </AdditionalItemProperty> >> </ItemInstance> >> </Item> >> </CatalogueLine> >> <CatalogueLine> >> <Item> >> <Description>Shirt</Description> >> <ItemInstance> >> ... >> </ItemInstance> >> <ItemInstance> >> ... >> </ItemInstance> >> </Item> >> </CatalogueLine> >> ... >> </Catalogue> >> >> The most retail systems use a SKU to identify the unique combination >> of say Product-Size-Colour. Have I got this right to put it in the >> ItemInstance's SerialID? >> >> Does anything seem glaringly wrong about this? >> >> --------------------------------------------------------------------- >> 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 > -- 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]