Thanks for responding Dan. I thought that one of the good features of
substitution groups is that you can always substitute for a global element.
However, it is required to declare your substitution so that it is always
explicit what the content model is. The way we have proposed the use of
substitution groups, a schema extension explicitly declares the substitutions
made. In the instance document the substitutions are delineated by the custom
name space qualifier that preceded the standard un-substituted name.
Also, we have not been able to make redefine work in this application due
to the following:
1) UBL document schemas import code list schemas. Therefore in a derived
schema (that can't alter either the ubl schemas or the underlying code lists)
errors are generated because the unredefined schemas had to be imported into the
document schemas. We have tried various schemes to overcome this. Can you make
it work? Remember, no changes in the code lists or the ubl schemas, only in the
custom schemas.
2) Redefine can't extend an enumerated code list, only restrict it.
This means that the base definition has to be non-enumerated. Then you can't
validate against the standard code list without redefining to it.
If a redefine solution could work this would be most ideal. Until then, I
favor substitution groups.
Marty
In a message dated 8/29/2005 7:09:22 P.M. Eastern Daylight Time,
DVINT@acord.org writes:
I do not like using
them because there is no way to know what the final content model is without
some tool support. What I don’t like is that looking at the content model I
can’t tell that a substitution is allowed. I have to track down all the
elements that can be substituted, without there being some flag on the head
element to indicate substitutions are being made. Sort of a good and bad point
about them, is they also require all the substituted values to be based upon
the same type, this is not always a good
requirement.
Instead of this,
ACORD has decided to live with the minor namespace issues associated with
redefine and prefer this approach for extensions and
restrictions.
..dan
From:
Burnsmarty@aol.com [mailto:Burnsmarty@aol.com]
Sent: Monday, August 29, 2005 3:40
PM
To:
ubl@lists.oasis-open.org
Subject: [ubl] Substitution Groups - Use
'em or lose 'em?
We are
working on extensibility models for standardized business exchange
schemas.
These schemas, under development by several standards organizations
make
extensive use of hierarchical
schemas and namespaces, some of which
include schemas developed by third
parties.
When a user or user community seeks to use these schemas, and,
needs to
modify them in some way (without altering the underlying
standardized
schemas), substitution groups can be a powerful and explicit
mechanism for
such extensions and restrictions.
Several participants
in these standard schema efforts have expressed reserve
from utilizing the
W3C mechanism of substitution groups due to their
experience with
non-uniform support of parsers for this schema feature.
In your
experience, what are the concerns or recommendations on the
incorporation
of substitution groups into the naming and design rules of
standardized
schemas?
Should substitution groups be relied upon as an extension
mechanism?
Marty Burns
Hypertek, Inc.
P +1(301)315-9101
E
burnsmarty@aol.com