Mark,
Are you arguing with the desirability of:
Extensibility?
Substitution Groups?
Both?
The use of substitution groups complements the suggested use of unions in
extending code lists in wd-ubl-cmsc-cmguidelines-1.0.html. I think that without
substitution groups, this mechanism doesn't work.
When a user community needs to extend or restrict UBL for their own
reasons, it is desirable to use a mechanism that forces the implementer to
declare the extensions explicitly. Substitution groups does this because in
order to validate an instance the definition of the substituting type must be
present. Also, the designer of the base schemas ensures the type
consistency of the substitutable information.
I believe what is being proposed is not that substitution groups are
necessarily used extensively within UBL schemas. What is being proposed is
that the schemas be designed so that the substitution group mechanism can be
utilized in extending the schemas in a clean and traceable way (that is the
extensions are explicit in the referenced schema in the instance document). If
substitution groups are used in UBL schemas they would only need to be used in
the code list schemas themselves to allow an unconstrained or enumeration
constrained set of values to be used in the code list.
What this requires of UBL primarily is the extensive use of global elements
(the ones that are substitutable), and, code list schema design and usage that
facilitates the extension mechanism.
Marty
In a message dated 7/19/2005 8:30:45 A.M. Eastern Daylight Time,
writes:
Global seems to me
> to tie in very much with
type
> oriented schemas
Actually, most arguments for local are
centered around managing by types
rather than types and
elements.
>and that in turn ties in with polymorhism (which
>
requires the global elements as well
> as the global types).
I
assume you mean named types since there are no such thing as
global
types.
>In other words
> it seems to me that the
industry,
> where advocating global schemas
> (increasingly so, it
seems) does
> seem to do so with features such
> as inheritance /
polymorphic
> treatment of types strongly in mind,
I would be
interested in any research related to polymorphic treatment
of types other
than Arofan's paper since my google can't seem to find
any.
> along with the growing tool and
> other standard support
(XSLT 2, etc).
Once again, just because a tool supports a feature, that
is not a
justifiable reason for using the feature. Else we will just
use <any>
and allow customizers free
reign.
Mark
---------------------------------------------------------------------
To
unsubscribe from this mail list, you must leave the OASIS TC that
generates
this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
