OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

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

Subject: RE: [ubl] Substitution Groups - Use 'em or lose 'em?



From: Burnsmarty@aol.com [mailto:Burnsmarty@aol.com]
Sent: Monday, August 29, 2005 4:53 PM
To: Vint, Dan; ubl@lists.oasis-open.org
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. ;-)







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.




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 hier
archical 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



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