RE: [ubl-dev] looking for practical examples

[Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>]

Have the 1,500 data elements been de-duped?  In not, perhaps a de-duping
exercise could be done. Is there a handy list? 

Apart from dupes, a 1,500 term vocabulary does not seem excessive for the
eBusiness B2B cycle.

On the other hand, in the world of internal systems and the subject that
started this thread, inventory system, 1,500 data fields hardly begins to
suffice. As I recall, a large retail bank did an inventory and found that it
had more 20,000 data fields. Although people complain about SAP's size (with
many more tables than there are UBL data elements), every SAP data element
has some major constituency that loves it. You just cannot do with out data
fields like VERPR - Moving average price/periodic unit price, or VKSAL Value
of total valuated stock at sale price. 

As to reducing the number of candidate fields per document, creating more
granular documents in order to have fewer fields per document makes managing
document roles and boundaries an issue (e.g., distinguishing among external
purchase orders, orders from stock, orders for stock and maintenance work
orders that have embedded orders for parts, particularly if it is not clear
to the buyer in advance where the part will come from). Also the
combinations of document-to-field increase and change management issues
arise. If document A changes, but document B does not, their shared data
fields may diverge, leading to the proliferation of new fields). 

The ideal design for a transaction-oriented environment such as UBL is one
"document" per action verb (e.g., to buy, to ship, to receive, to invoice,
to pay, etc.). Presumably UBL configuration tools can help users check off
the fields available and relevant to the transaction. In effect, a UBL
transaction is an RDF "triple" (subject-verb-predicate) with the verb
implied by document type (order implies and instantiates the verb "to
order"). RDF people tend to focus on "to be," which is not much of a verb.


					Fulton Wilcox
					Colts Neck Solutions LLC

-----Original Message-----
From: Stephen Green [mailto:stephengreenubl@gmail.com] 
Sent: Saturday, February 14, 2009 6:43 AM
To: Alexander Whillas
Cc: ubl-dev@lists.oasis-open.org
Subject: Re: [ubl-dev] looking for practical examples

>
> 1. Comprehend the 1500+ elements of UBL

I agree there are far too many elements per document to have to learn.
I would have *much* preferred more document type each with far fewer
elements. Then you might have to learn 50 instead of 30 document
purposes but maybe as a result of spending a little more time finding
the right document you might only have to learn the elements which are
most interesting to you - say 500 instead of 1500. But look at OAGIS
where there seem to be hundreds of different messages to learn. That
puts me off too. I might only need one or two of those but how do I know
that and how do I know which ones exactly.

I think this might still happen if the work developed sufficiently in the
context area. You would then have to know which documment you need
and also which context applies to you to determine which subset or
profile applies to you (as with OIOUBL). Then the document you end
up with might involve learning just 500 elements, all of which are likely
to be of use to you.

I'm guessing the reason 1500 elements to learn is a problem because you
don't get enough business value from each element. Otherwise that learning
would be interesting and worthwhile. That's exactly why we foster subsets
- to allow people to home in on the elements with most business value and
have a way to ignore the others. You might, say, have decided that shipping
information is of no value to your application. You need a subset which
allows you to ignore it, or you need a UBL document type which ignores it.
I prefer the latter - create the document you want as a subset but turn it
into an actual new document type. I would like to see this happening in UBL.
One way to get what you want is to participate but there's no guarantee
that the other participants will agree with you or believe that your own
business case is sufficiently representative to warrant the inclusion in a
new
minor version. Plus, even if they did, it might result in the 'hundreds of
document types to choose from and therefore understand' problem. Maybe
hundreds of documents to know about is better than thousands of elements
to know about but it is, I think, more off-putting than the element bloat.

Interesting though to see the requirement for multiple currencies. Documents
which support such things are going to need more elements or logic to learn
aren't they. Case in point. You want features which add to what others will
have
to learn. The best the UBL TC could do, it seems, was to weigh such
conflicting
needs and provide a discretionary optimum. It took years of work and a lot
of
expense and this is what resulted. I wouldn't recommend anyone trying it all
again in the hope of doing better. Better to start or join a
subsetting initiative.

Of course, for those without the time to invest it is necessary to get into
UBL
or equivalent) and get out again as quickly as possible with as much
achieved
as possible. If not getting into it in the first place is preferable
then maybe there
is not enough reason to be looking at using standardised XML messages and
you
should ignore the Tim Bray article and 'roll your own'. I tend to respect
that
choice. If learning thousands of elements or hundreds of elements and
hundreds
of document purposes is not worth your while then maybe roll your own is. No
problem. If you were implementing an invoicing and payment system then you
might find the need for a standard more pressing and also more
profitable to spend
time on. That is more the scenario we were addressing with UBL.

:-) Massive number of emails to read too :-)

Best regards

- Steve

2009/2/14 Alexander Whillas <whillas@gmail.com>:
> 2009/2/13 Fulton Wilcox <fulton.wilcox@coltsnecksolutions.com>:
>
>> As to whether standards can keep up with requirements, for most users
they
>> are far ahead.
>
> If this is the case, why do I have to invent an Inventory document,
> and its looking more like I have to.
>
> There is another option that XML opens up and that is XSLTs to convert
> one format into another. If I go with UBL, I have to:
>
> 1. Comprehend the 1500+ elements of UBL
> 2. Create XSD for the Inventory document
> 3. Implement
>
> Where as if I create an ad-hoc XML inventory document I eliminate step
> 1 and speed up step 2 and in future if I need to interface with UBL
> systems I (or who ever) writes an XSL Transformation.
>
> Can you see how step 1 here is a disincentive to the developer with a
> limited time/budget?
>
>> In particular, many well-functioning inventory systems become
>> chronic problems because they were not "future-proofed" for success. For
>> example, the requirements spec did not even address multi-currency, the
>> system was hard-coded to the spec, but suddenly a requirement emerges to
do
>> business in Canada or China.
>
> Actually, how does UBL handle multi-currency pricing? I was looking at
> Catalogue and the only mention of pricing is in
>
> Catalogue
>    CalalogueLine
>        Item
>            RequiredItemLocationQuantity?!?
>                Price
>
> Is there an attribute here somewhere that defines currency?
>
> regards
>
> alex
>
> ---------------------------------------------------------------------
> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org