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

> 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

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