below
From:
[mailto:]
Sent: Monday, August 29, 2005 4:53
PM
To: Vint,
Dan;
Subject: Re: [ubl] Substitution
Groups - Use 'em or lose 'em?
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.
<dan>Yeah, we require the use of a
namespace as well in our redefine. My problem is in tracking down how the substitutions
can be made. So I have a conent model of (a, b, c) but my data stream ends up
with a, G, c – is G valid? I don’t know I now have to go search for head=”b” to see if someone
created a substitution. As an extension this might not be as bad, but I certainly
don’t like it as a general design principle for the core standard. It
really depends on how well it is managed and actually used.
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.
<dan>Those are really the same basic
problem that you can’t extend a code list once a set of enumerations have
been defined. I posted to one of the UBL lists the “workaround” (I
won’t dignify it with solution) that we came up with. First we don’t
define all our code lists externally, but I think this would still work, just
be more files to deal with. So our core schema has a definition for a code list
that just gives it a name and in the case of an ACORD list, we base this on
QName. That is the definition in our core/base schema with all the other
content. We then also provide a redefining schema that points at this base
file. The only thing in this schema is the redefinition of all the code lists
types with their restricted values. This provides a couple of uses. First, some
of our members did not want the schema to validate the codes, they wanted to do
this in there own application. So these folks will just use this base schema
for their processing. Those that want code validation in the schema will use
the redefining schema with the base file to provide this functionality. This works
nicely. The ugly part is how we resolve the extensions. Basically we are telling
people to edit the redefine schema directly and add their values there.
If a redefine solution could work this would
be most ideal. Until then, I favor substitution groups.
<dan>We looked at substitution
groups for code values as well, the problem was it introduced another element
you had to process from what we saw. So if C was the element with the list,
your extensions would be in acme:D so now I have to look in two places for code
values.
<dan>This whole extension area seems
to have only been thought through partially. There doesn’t seem to be any
good solution out there, so it is a matter of picking the least offensive
methodology – and one man’s offensive is another’s solution. ;-)
..dan
Marty
In a message dated 8/29/2005 7:09:22 P.M.
Eastern Daylight Time, 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:
[mailto:]
Sent: Monday, August 29, 2005 3:40
PM
To:
Subject: [ubl] Substitution Groups
- Use 'em or lose 'em?
All,
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
