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] Substitution Groups for Derivation


Hi Chee-Kai

There is plenty in the 2005 spring and summer ubl lists about all
this (http://lists.oasis-open.org/archives/ubl/) but some points:

I don't think the rule in UBL 1.0 NDR applies outside of
the process of producing the read-only UBL schemas (the
TC work), even though the scope is stated as extending
beyond the UBL TC. The consideration of having rules for
customisers still hasn't been included in the UBL NDR. It
may be that NDR for UBl will never cover customisation.
The most it covers is minor versioning and there was a flaw
in how that was doen in the UBL 1.0 NDR (in my opinion but
accepted in the TC I think) - due mainly to the presence
of non-global elements for IDs and Codes in UBL 1.0 but
perhaps a little due to what seemed to me to be efforts to
resolve in the UBL NDR incompatibilites between ATG2 and UBL
approaches. The ATG2 approach was then to emphasise redeclaration
of much or all of the schema(s) when a change was required for
minor versions (I'm no expert on this so I'd not want this view
of mine to be relied on). The UBL design had always aimed at
allowing use of W3C Schema 'polymorphism' through substitution
groups for customisations which got broken in UBL 1.0 due to the
allowance of the local element declarations (see papers by
Eduardo Gutentag and Arofan Gregory). This was always in the
backgound in the NDR work, even though this got broken. So
mending it with UBL 2 is a primary goal behind UBL 2 (the
original goal which later expanded to include extra documents
and some change of names, etc).

The complexity of using W3C Schema redefine and substitution groups
and the complexity of how tools cope with it may be influencing
UBL's TC towards emphasising and enabling the other option of
extension points and there may be influence too from the will to
align with the ATG2 NDR more (though that might not happen altogether
I think - another thorny discussion point - should there be two separate
ways to produce schemas and their derivatives?).

I think a major thing to consider when viewing arguments here is
that there are preferences of software products towards one method
or another and some don't like GoE schemas or substitution groups.

I do agree though that the issue should mainly be a consideration
of the use and production of the instances. We tried to do this in
the versioning working group but the requirements and technologies
are a moving target and in the end it always seems to come back to
principles (OO and polymorphism of types being a key one with regard
to proving a schema preserves instance backwards compatibility and
having a kind of audit trail of this). Then there is the principle
too of having an ability to simply define what is compatible, hence
the favour towards the extension points with xsd:any. But in my view
it is not either-or but both-and.

All the best

Steve






Quoting Chin Chee-Kai <cheekai@softml.net>:

> Stephen,
>
> Hi, and thanks for updating on the use of <substitutionGroup> in UBL.
> I don't think I should, but should I  be interpreting that UBL adopts
> GoE (in v1.0 & v2.0) just, or may be less strongly, perhaps, because of
> the option to use <substitutionGroup>?
>
> If the issue of discussion has been fixed around <substitutionGroup>,
> then I absolutely agree with you that since by definition, as you
> said, <substitutionGroup> has to have global elements, it is worthwhile
> to consider favourably of GoE.  But even admitting this for a split
> second, <substitutionGroup> only requires the substitutable group
> of elements to be globally defined.  If this therefore means a general
> policy to globalise all elements, there may still be a need reasons
> sufficiently strong, other than just <substitutionGroup>,
> to do just that (of globalising all elements).
>
>> From the end-user perspective, however, it would seem like putting
> the cart in front of the horse by the asserted definition that
> human must lead horse rather than horse being in front of human  :)
> Not to draw the analogy too far (since I don't take horse-powered
> rides much), what is necessary is the backwards compatibility of
> user's data instances, both compatibility with future data instances
> stored in future upgraded formats as well as hopefully with future
> validating systems using upgraded specs (eg. future versions of UBL).
>
> If keeping easy compatibility at schema space would necessitate
> reformatting of all past user data instances so that future processing
> systems could also process past data  instances, how much benefit
> can user derive?   I'm not saying <substitutionGroup> will cause
> this to happen, but I thought a proposed compatibility argument ought
> to be centered in the data space first (instead of perhaps schema,
> software or other digital spaces)  before expanding further on its
> benefits and downsides.
>
> On schema extensibility, end-users defer extensions to developers
> and implementors, who then seek compatible ways to implement those
> business extensions.  Schema has a couple of ways to allow that.
> UBL archive is probably filled with lots of discussions on those
> possibilities (including, of course, Eve Maler's paper which Ken
> referenced earlier).  But up until UBL 1.0's NDR, UBL is still
> recommending
>
> "[GXS5] The xsd:SubstitutionGroup feature MUST NOT be used"
>
> (the capitalised 'S' is verbatim)  and there's no discussion of the
> "abstract" usage.   I'm not sure if it has changed in UBL 2.0, but
> if now the thinking has changed, and <substitutionGroup> is now
> permissible to some degree, then there ought to be some discussion
> of "abstract" element usage and its consequences.  And that's
> only one way to customise, one that MUST (in RFC sense) require
> use of global elements.
>         (<substitutionGroup> ===> global elements)
>
> Let's step back and think the other way around.  Do we need
> global elements?  (asking myself).
> If the answer, based on consideration on various angles but not due
> to requirements or artefacts of schema, is "yes", then certainly
> <substitutionGroup>  comes for 'free', whether it is important or
> not, used or not used.  So then,
>         (global elements =X=> <substitutionGroup>)
>
> (global elements does not require use of <substitutionGroup>,
> and so to global or not to global is an independent argument
> separate from use or not use <substitutionGroup>).
>
> But what if the answer is "no"?  That global elements do not
> contribute to end-user's benefit?  What if it is only to satisfy
> specification requirements or developers' convenience?
>
> Again, I'm not making any judgment based on "feel" or "faith" or
> the need to maintain any legacy Venetian Blind codes.  But the results
> which I'll share with you and the list for independent verification
> might either help you (as in the group who believe GoE is better
> than VB) convince me, or the other way around.
>
> For now, with those results at least, I'm leaning more towards
> globally sharing of types (reusable types) and
> zero global element  (Venetian Totally Blind?).
>
>
>
> Best Regards,
> Chin Chee-Kai
> SoftML
> Tel: +65-6820-2979
> Fax: +65-6820-2979
> Email: cheekai@SoftML.Net
> http://SoftML.Net/
>
>
> On Fri, 19 May 2006 stephen.green@systml.co.uk wrote:
>
>>> Hi Chee-Kai
>>>
>>> The key point is now, historically, that substitution groups
>>> absolutely require that the elements, at least, be declared
>>> globally. Even though we have urged caution in what should
>>> and should not be expected when using them regarding datatypes,
>>> it remains a key benefit that the standard schemas should not
>>> by their design prevent others using substitution groups (plus
>>> the UBL TC voted to keep options open on whether they are used
>>> in future for minor versioning as it is the key way to ensure
>>> backwards compatibility and this is important for minor versions).
>>> I actually think, myself, that all global elements should be
>>> best practise for any standards schemas which might need
>>> customisation.
>>>
>>> I have to put a health warning on the possibility of a long thread
>>> on this issue though :-)
>>>
>>> All the best
>>>
>>> Steve
>>>
>>>
>>> Quoting Chin Chee-Kai <cheekai@softml.net>:
>>>
>>>> On Thu, 18 May 2006, G. Ken Holman wrote:
>>>>
>>>>>>> H'mmm, ok, I'm starting to understand where you're coming from here.
>>>>>>> Educate me a bit here. Is UBL defined principally of global
>>>>>>> elements/types ?
>>>>>>
>>>>>> I think that's an orthogonal question, but yes UBL does follow the
>>>>>> "Garden of Eden" characterization of schema expression where all
>>>>>> elements and types are defined globally and there are no anonymous
>>>>>> types.  Other characterizations of schema design patterns are termed
>>>>>> "Russian Doll" (document element is global, all other local, all
>>>>>> types local), "Salami Slice" (all elements global, all types local)
>>>>>> and "Venetian Blind" (document element is global, all other local,
>>>>>> all types global).
>>>>>>
>>>>>> One of our many reasons to thank Eve Maler:
>>>>>>
>>>>>>
>>>>>> http://www.idealliance.org/papers/xml02/dx_xml02/papers/05-01-02/05-01-02.html
>>>>>>
>>>>>> I hope this helps.
>>>>>>
>>>>>> . . . . . . . . . . . . Ken
>>>>
>>>> Thanks for a the nice URL link and Eve Maler's summary.  The article
>>>> exposes the various major modes of schema design methods and argues for
>>>> the Garden of Eden approach as adopted by UBL 1.0 (and also UBL 2.0?).
>>>> I was looking again at the global vs local issues when you bring up
>>>> this URL.  So it comes in just in time.
>>>>
>>>> With all respects going to Eve's contribution and your (and probably
>>>> other UBL members') belief about why global (GoE) approach is better
>>>> over local, I am beginning to see evidence of such extreme approach
>>>> (of globalising everything) as doing a disservice to end-user reusing
>>>> UBL and its components.
>>>>
>>>> To qualify my words, globally sharing of types is alright, but globally
>>>> sharing of elements is showing signs of problems.  If this is what's
>>>> called the Venetian Blind approach, then yes, I believe I'm beginning
>>>> to see more advantages of VB than GoE.
>>>>
>>>> Ref Eve's paper, the primary 3 points on why GoE is better than VB are
>>>> (1) mixture of element (namespace) qualifications,
>>>> (2) potential breakage of software
>>>> (3) accidental breakage due to elementFormDefault (again on software
>>>>    breakage)
>>>>
>>>> I understand the concerns at that time may be different from the concerns
>>>> now, but I don't see how and why schema designs should be done in a way
>>>> that puts prevention of software breakage first (ie, easier for
>>>> programmers and software developers).  All things being equal, I'd agree
>>>> this could be considered, but there seems to be more at stake than
>>>> software breakage.  There may be other concerns that Eve hadn't put
>>>> in that article (to justify GoE over VB), so if there are further
>>>> article updates, I'll be very glad if you can point them out to me
>>>> as well.
>>>>
>>>> Alright, I'm not here to start another religious debate on
>>>> global vs local.  I only wish to point out that there're also
>>>> disadvantages inherent in the way UBL schemas are currently designed,
>>>> and what's "best" then doesn't seem the same now.
>>>>
>>>> In the next mail (when I get to it), I'll like to seek your help (again)
>>>> to check if the results and conclusions I got make some sort of sense.
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>
>>>> Best Regards,
>>>> Chin Chee-Kai
>>>> SoftML
>>>> Tel: +65-6820-2979
>>>> Fax: +65-6820-2979
>>>> Email: cheekai@SoftML.Net
>>>> http://SoftML.Net/
>>>>
>>>>








> Hi Ken
>
> Comments inline below -
>
> Quoting "G. Ken Holman" <gkholman@CraneSoftwrights.com>:
>
>> I'm going to chime in briefly to get a better understand of needs 
>> ... but I don't have a comment on substitution groups, but on 
>> extensibility.  This impacts the work I'm trying to do with 
>> extensibility in UBL.
>>
>> At 2006-05-19 16:55 +0800, Chin Chee-Kai wrote:
>>> On schema extensibility, end-users defer extensions to developers
>>> and implementors, who then seek compatible ways to implement those
>>> business extensions.
>>
>> Fine ...
>>
>>> Schema has a couple of ways to allow that.
>>
>> But with the recent efforts of Steve and Joe to demonstrate on this 
>> list any extensibility using W3C Schema features, I think it is 
>> clear the features are not sufficient to the task.
>
> An important point is that the previous discussion was about datatypes
> - that is both CCTS 'qualified and unqualified datatypes' and their
> underlying W3C XML Schema datatypes. These were found to be difficult to
> customise using W3C Schema redefine and substitution group techniques
> and possibly any W3C Schema form of derivation. Schematron and other
> second layer methods seem to be preferable for such datatypes.
>
> This discussion didn't really consider the other types in UBL, complex
> types called Business Information Entities(BIEs). For those not familiar
> with the Core Components technical Specification (CCTS, ISO 15000-5)
> these in turn use by reference the qualified and unqualified CCTS
> datatypes. It still remains that UBL was primarily designed to allow such
> BIEs to be extended and restricted using the W3C XML Schema derivation
> methodology of substitution groups (although there was a rule preventing
> the use of such actually in the read-only schemas, which helps implementers
> use them for customisation).
>
> It may still be (the last I heard the TC had decided to keep it open) that
> UBL minor versions will use this technique to ensure backwards compatibility
> from previous versions. I created several prototypes of UBL 2 schemas to
> prove the workability of this. One of my action items for next week's plenary
> is to test any schemas for UBL 2 second public review which we might produce
> to see that this workability is intact, likewise that customisation will
> work this way too.
>
> This is a whole different thing to datatype derivation. It goes back to
> work done by a UBL working group last year after which it was agreed that
> the next set of UBL schemas should use all global elements and types (Garden
> of Eden) to at least allow this and that this would mean the next release
> being a major one, hence UBL 2. The decision of whether to use susbtitution
> groups or redefine for minor versioning was then deferred, as was the
> decision as to whether to actually promote their use for customisation.
> UBL TC would just ensure the options were open for either by using the GoE
> design. The customisation decision is awaiting discussion after the UBL 2
> second public review schemas have been produced (imminent now hopefully).
>
> It might be a good time to discuss this in view of the above -
> if folks aren't too worn out from the datatypes discussion (and with catching
> up with those postings) :-)
>
>
>>
>> If developers and implementers implemented the business extensions 
>> solely within the new extension point being provided in the next 
>> draft UBL 2 then there (1) won't be a need to shoehorn insufficient 
>> validation facilities and (2) implementations will be true to the 
>> compatibility measurement with UBL 2 because all instances will 
>> continue to validate according to the normative UBL 2 schemas 
>> regardless of the embedded extensions.
>
> I agree this is plausible but the option to use substitution groups
> is not being precluded and in my mind at least, for BIEs, remains
> a key feature of the planned UBL version 2.
>
>>
>> I feel this compatibility test will promote interoperability and I 
>> believe these benefits will outweigh possible implementation 
>> concerns.
>>
>> . . . . . . Ken
>>
>
> This is a good idea I think. I still feel it is best practise to allow
> both options. A key factor is that this will be true too if substitution
> groups are used properly (and simply too).
>
> The whole thread for this is rather fragmented but can be found
> in the following with relevant items marked '[ver]' in the subject
> http://lists.oasis-open.org/archives/ubl/200504/threads.html
> see also
> http://lists.oasis-open.org/archives/ubl/200502/msg00037.html
>
> Do folk have the stomach for another lengthy discussion ?  :-)
>
> All the best
>
> Steve
>
>
>
>
> All the best
>
> Steve
>
>> --
>> Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
>> Also for XSL-FO/XSLT training:    Minneapolis, MN 2006-07-31/08-04
>> Also for XML/XSLT/XSL-FO/UBL training: Varo,Denmark 06-09-25/10-06
>> World-wide corporate, govt. & user group UBL, XSL, & XML 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
>>
>>
>> ---------------------------------------------------------------------
>> This publicly archived list supports open discussion on implementing 
>> the UBL OASIS Standard. To minimize spam in the
>> archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Alternately, using email: list-[un]subscribe@lists.oasis-open.org
>> List archives: http://lists.oasis-open.org/archives/ubl-dev/
>> Committee homepage: http://www.oasis-open.org/committees/ubl/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>> Join OASIS: http://www.oasis-open.org/join/
>>
>>
>
>
>
>
> ---------------------------------------------------------------------
> This publicly archived list supports open discussion on implementing 
> the UBL OASIS Standard. To minimize spam in the
> archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Alternately, using email: list-[un]subscribe@lists.oasis-open.org
> List archives: http://lists.oasis-open.org/archives/ubl-dev/
> Committee homepage: http://www.oasis-open.org/committees/ubl/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Join OASIS: http://www.oasis-open.org/join/
>
>





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