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: SV: [ubl-dev] UBL Basics.. try "Productivity"....


At 2007-02-11 09:24 +1100, David Lyon wrote:
>We simply have different perspectives because we are working in 
>different environments.
>
>On to the next comment...
>
>G. Ken Holman wrote:
>>
>>But, if vendors call the XML they produce "UBL" and it isn't "UBL" 
>>then there will be users who won't understand the nuances and won't 
>>see why their UBL doesn't work with other people's UBL, and they 
>>will blame UBL for not working and may not think to blame the 
>>vendors who don't conform.
>If you publish "UBL" as an open standard to be implemented around 
>the world, it's only inevitable that it will be localised and 
>adapted to particular use scenarios in certain places. It's going to 
>end up slightly different in different industries, yes or no?

Yes and no.  Yes they will be different in different industries and 
no they will not be different than standard UBL ... this is the 
concept of "customization" (using the term adopted in the June UBL TC 
meeting, there is some ongoing discussion of appropriate terminology 
to use here so this term may be adapted differently in the future).

So, bear with me:  a UBL customization is a specification of a 
catalogue of a subset of existing UBL information items and a set of 
extension information items not defined by UBL as required by a 
community of users, be it an industry, a government (e.g. Denmark), a 
group of governments (e.g. North European Subset), or even a company 
(e.g. I'm creating a Crane customization in support of my corporate invoices).

What is key is that instances of a UBL customization are instances of 
"standard" UBL because they all validate against the normative 
published W3C Schema UBL artefacts.

>You have to concede that UBL is quite complex and can't just "be 
>implemented wholus bolus" within an SME, just like that.

Absolutely!  That is why we have this concept of customizations, and 
why we defined it in a way that customizations are all instance-level 
conforming to the standardized UBL specification.

I fully expect preisshare to establish your own customization of UBL 
Catalogue for your requirements for your community of users.  You may 
even choose to create a schema for it (there is a free developer 
resource on our corporate web site with which one can create W3C 
Schema expressions of a subset of UBL information items.  That schema 
does not represent UBL, but instances of that schema are UBL 
instances because they all validate against the published UBL schemas.

A customization can be a formalism expressing the support of UBL by a 
community of practice.  The artefacts of this formalism can be very 
useful in processing UBL information.  That information does have to 
be UBL ... that is, at the document level, it has to validate against 
the UBL schemas.

>The bar is set very high, whether intentionally or not.

Absolutely it was intentional to standardized the largest suite of 
useful constructs suitable for many users of UBL, but each community 
of practice can choose to use that customization of UBL suitable for 
their needs.

And every document has an extension point with which a community of 
practice can standardized a serialization of business objects they 
need that is not defined by UBL.

You have all of these constructs to draw on to establish which 
standardized UBL labels you will use to label an XML instance with 
your information in a way that you can reliably exchange your 
information with a trading partner who understands the standardized 
UBL labels as you do.

>Anyway, I think your assertions are quite bogus in regards to blame. 
>Simply because you already have your exit strategy in place.
>
>If anything goes wrong for a client, you simply respond with "oh but 
>that isn't really UBL"... and then procede to ask for money to set 
>the record straight for them. The client will end up confused, only 
>after you have confused them.
>
>So that's chaos theory for today... life and technology will move on 
>regardless...

Please help me understand what you are saying here.  I do not wish my 
assertions to be interpreted as "bogus" and I'm more than willing to 
set the record/archive straight.

Stephen presented an instance he called an instance of UBL Catalogue 
... from my understanding of the committee definition of UBL 
document-level conformance, it is not an instance of UBL Catalogue, 
and I didn't want you to believe that it is.

Where specifically did you feel I was making a bogus 
assertion?  Where did I ask for money to set the record straight?

I was saying "that instance isn't UBL" because if someone attempts to 
use it as UBL, then applications expecting UBL cannot use it ... I 
honestly think it would be the user who is confused if I hadn't said 
something.  And all I'm asking is that any hocus-pocus be done behind 
the curtain and that anything and everything that is exposed at the 
document markup level be validated against the published UBL schemas.

Is this more clear than how I've expressed myself earlier in this thread?

Thank you for the valuable feedback.  You are, in fact, one of the 
kinds of candidate UBL users for whom we have created this 
specification, and when you use the specification as designed, it 
will work well for you.  I did not want you to be led into thinking 
that an XML document with no namespaces and the same local names as 
is used in the UBL vocabulary is a UBL document.  It isn't, and I was 
trying to help.

. . . . . . . . . . . . Ken

--
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/u/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/u/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal



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