Re: [ubl-dev] Customizing where 'Simpler-Than-UBL' (STU) is needed

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Tim, I have no problems with these ideas you've expressed of 
compatibility and deriving common patterns from models for the 
creation of alternative vocabularies identified as being UBL compatible.

In my mind, that isn't what is up for discussion this week.

Following the thread, you'll see my comments this week were all 
triggered by and focused on the following:

At 2007-02-09 09:11 -0700, stephen.green@systml.co.uk wrote:
>I just got to a fairly stable state with a customization of
>the UBL Catalogue for an opensource price list product. After
>making a schema as previously mentioned with zero namespaces
>(or at most one) and just one schema file I went on to
>customise the Catalogue proper UBL schema files too.
>...
>It does work so far
>though and a simple transformation both to and from UBL proper
>instances is made possible while allowing validation against a
>necessarily simpler schema. Reiterating:- that's a schema with no
>more than one namespace and no more than one module/physical file.

*In the context of the above* David brought up that this was merely a 
different projection of the UBL models, in this case using no 
namespaces, but otherwise the constructs were identical.  And the 
comments about "lego bricks" being the same entities just not in any 
namespace.  What David and Stephen are doing here is different than 
the topics you bring up below regarding compatibility ... unless I'm 
mistaken in which case I'll step back.

It is only their introduced ambiguity (and I think the resulting user 
confusion) that I am addressing in my comments ... I am not talking 
about the Singapore discussions of conformance/compatibility that I 
support and look forward to formalizing at a committee level.

Does this clarify the nature of my comments?  I apologize if I left 
the impression with you that I was abandoning the successful 
discussions that we had in this regard.

Thanks!

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

At 2007-02-10 12:44 +0900, Tim McGrath wrote:
>This is indeed a key point that we should recognize.
>
>In the current draft white paper on customization i tried to make 
>the point that we must distinguish conformance from the idea of 
>compatibility. I will paraphrase this as...
>
>Document conformance for UBL means exactly one thing. A conforming 
>document doesn't have any surprises for the business systems that 
>were designed for the UBL standard. The simple and clear test is 
>that the documents must validate against the relevant UBL schema. An 
>XML instance is considered conforming to UBL if there are no 
>constraint violations when validating the instance against the 
>published UBL schema. This simple fact enables software developers 
>to proceed with some comfort that not only will their software have 
>clear specifications but that correctness of their solutions can be verified.
>
>I take compatibility to mean consistent or in keeping with the 
>principles of something. It has a softer emphasis and suggests 
>common agreement on basic principles. I mean it to suggest a shared 
>heritage but without necessarily guaranteeing conformance.
>
>It is reasonable to expect and encourage implementations that cannot 
>or do not require conformance to develop compatible customizations 
>where feasible.
>
>So all documents conforming to the UBL standard will be UBL 
>compatible but not necessarily all UBL compatible documents conform 
>to the UBL standard.
>
>We need to make this point so that we can appreciate the benefits of 
>developing UBL compatible documents. The degree of common 
>understanding will vary because they are customizations.
>We cannot expect automatic conformance but we can expect some degree 
>of familiarity through the re-use of common patterns.
>
>
>David RR Webber (XML) wrote:
>>Ken and Steve,
>>This is indeed an interesting moment in time and space.
>>Let me try and summarize and unravel the XML knot here.
>>1) UBL is defined as a set of XSD schemas - to which things have to be
>>conformant.
>>2) Payloads are in XML format
>>3) Steve has a subset that uses the same UBL entities and constructs and
>>approach as the regular schemas
>>     (the Lego bricks if we will)
>>Now - Conformant is driven by 1) - however something may be Compatible
>>with 1) - e.g. using 3) if there is a simple transformation that can be
>>applied that renders 2) as something that will pass 1).
>>I believe that is what we are seeing here - not strict conformance - but
>>compatible with - hence its UBL-ish -while not being exactly UBL as per
>>the v2.0 XSD.
>>However - I think Steve's point is that its still in the spirit of and
>>compatible with UBL since its using all the same "Lego" - but just is
>>simpler for people to do 2) - and handle the XML payloads.  From the
>>CCTS stance of course - Steve is correct - the XML is just a rendering
>>- so being compatible with the CCTS model of UBL can take many forms -
>>even EDI instances!?!?
>>DW
>>
>>"The way to be is to do" - Confucius (551-472 B.C.)
>
>--
>regards
>tim mcgrath
>phone: +618 93352228
>postal: po box 1289   fremantle    western australia 6160
>web: http://www.portcomm.com.au/tmcgrath


--
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/m/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/m/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal