Re: [ubl-dev] Substitution Groups for Derivation

[stephen.green@systml.co.uk]

Chee-Kai

Hi, just two questions really: How would you want to customise
the types - using redefine or redeclaring types under a different
namespace or some other way? I don't see how you can use
substitution groups since there are no abstracts in the main
schemas (and can't be with the NDR as it is). If the answer is
to redeclare then how can one still call it UBL or be sure one's
types are compatible with UBL (unless one is just customising the
document schemas which seems too limited to me).

All the best

Steve

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

> Stephen,
>
> Hi, that's a nice update on things, and I suspect I'm inadvertantly
> making you repeat some of those discussions, so, sorry but thanks
> for being patient and putting these things in perspective.
>
> For NDR, I'm afraid (for myself) that you could be right that
> about the scope of NDR not being actually applied outside of TC.
> Flaws (or bugs) would unfortunately always lie hidden somewhere,
> but that's part of evolution of standards, which hopefully means
> they'll get corrected in 2.0.
>
> However, for some local purposes, I've tried to do some comparative
> readings on UBL's NDR 1.0 as well as UNCEFACT's NDR (Draft 1.0,
> 2004 Aug 3,
> http://webster.disa.org/cefact-groups/atg/downloads/index.cfm/).
> One of the major findings was certainly that the latter advocated
> local elements while the former advised use of GoE (all global
> elements).  Whether for TC/UNCEFACT internal-only, or as advice
> to users and implementers, this is quite some gap to try to understand
> the rationale of each advice.
>
> But where I don't quite get is the unstated assumption that
> <substitionGroup> and 'polymorphism' SHOULD be used for customisation
> in UBL.  If the assumption is made, and with due respect to Eduardo
> Gutentag's and Arofan Gregory's contributions through the papers, I'm
> pretty sure all the arguments made would seem logical and proper.
> But it is the assumption I'm having some difficulty understanding.
>
> <substitutionGroup> requires global elements, so let's globalise
> all elements.  Question is, should all the elements within UBL
> be globalised?  Is that a good thing?
>
> Another question, somewhat on a level above this and enough cause
> for the reason I used "Global elements doing UBL a disservice" as
> subject, would be why the emphasis of customisation through elements?
> Would it not have the same, and I'd almost say better, effects
> through customisation (and thus re-use) of only the types?
>
> Just like to add that it is not my intention here to develop the
> UBL's customisation direction here;  it should be done within TC.
> But from user's perspective, at least I hope to get an understanding
> of the reasoning behind what might be very important decision
> directions affecting all the schemas, customised schemas, and
> consequently all the (possibly trillions?) of instances to come.
>
>
>
> 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
>>>
>>> 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/
>>>>
>
>
>
> ---------------------------------------------------------------------
> 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/
>
>