W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2002

RE: Restricting a substitution group using <choice>

From: Mark Feblowitz <mfeblowitz@frictionless.com>
Date: Fri, 15 Mar 2002 13:45:27 -0500
Message-ID: <4DBDB4044ABED31183C000508BA0E97F040AB970@fcpostal.frictionless.com>
To: "'Jeni Tennison'" <jeni@jenitennison.com>
Cc: xmlschema-dev@w3.org
Your suggestion to use existing members as the substitution group looks like
the right idea. I keep forgetting that we're dealing with relationships
between exemplars, not class-instance relationships. In our specific
example, it makes sense to do that.

Your adaptor schema is also an excellent suggestion.

Thanks,

Mark

----------------------------------------------------------------------------
----
 
Mark Feblowitz                                   [t] 617.715.7231
Frictionless Commerce Incorporated     [f] 617.495.0188 
XML Architect                                     [e]
mfeblowitz@frictionless.com
400 Technology Square, 9th Floor 
Cambridge, MA 02139 
www.frictionless.com  
 

 -----Original Message-----
From: 	Jeni Tennison [mailto:jeni@jenitennison.com] 
Sent:	Friday, March 15, 2002 1:33 PM
To:	Mark Feblowitz
Cc:	xmlschema-dev@w3.org
Subject:	Re: Restricting a substitution group using <choice>

Hi Mark,

> I've encountered a situation where I need to restrict the membership
> of a substitution group in type "ns1:A" and then, in type "ns2:A"
> which extends type "ns1:A", to have the benefit of including new
> substitution group members that are added in ns2.

I think that in these situations, you should make sure that the new
elements that you add are members of the substitution group of the
elements that you allow in the restricted type.

In your example, rather than making ns2:E4 a member of the ns1:E
substitution group, make it a member of the ns1:E1 or ns1:E2
substitution group.

I think that this makes sense logically -- the reason you want to
allow ns2:E4 is presumably because it is similar in some way to either
ns1:E1 or ns1:E2. You should, I think, articulate those similarities
in a substitution group hierarchy if you can.

> I know I could build ns2:A off of ns1:Base and then re-restrict. But
> what if ns1:A contains extensions or restrictions that belong as
> part of ns2:A? Will I have to maintain ns1:A and ns2:A separately
> and remember to replay edits from ns1:A on ns2:A?

What I'd do, I think, is create an adapter schema that redefined
ns1:A, so that the changes that you make to it ripple through to the
restricted and extended types derived from ns1:A in the rest of the
schema for ns1.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/
Received on Friday, 15 March 2002 13:46:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:14:30 GMT