Re: [ubl-dev] Re: Global elements doing UBL a disservice

[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/
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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/
>>
>>