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,
MCRAWFORD@lmi.org 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