[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Customizing where 'Simpler-Than-UBL' (STU) is needed
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]