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] Re: Global elements doing UBL a disservice


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





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