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

[Tim McGrath <tmcgrath@portcomm.com.au>]

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.)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org
>
>
>   

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160
web: http://www.portcomm.com.au/tmcgrath