Re: Schema Design: Composition vs Subclassing

Hi;

please forgive my impertinent interruption......

On Tue, 16 Apr 2002, Paul Kiel wrote:

> Thanks Jeni and Mark,
> 
> You both have hit the crux of the matter exactly.  I guess I was hoping for
> that magical "other option" that would meet our needs and remain simple.

the fact that one doesnt seem to exist for what is a very reasonable
problem has increased my dissatisfaction with pure XMLSchema to a crucial
point.

this isnt the only 'cant do that in XMLSchema' that i have experienced
lately. my own cross to bear has been co-occurence constraints.

> I think we are just plain stuck with creating a different Person for
> each transaction.

bleah! it's a solution of sorts, and it's probably fine if it's going to
only be 3 different Persons. but what if it's 15? or 50?

> This won't prevent me from creating a model for
> reference and consistency, however.  One that is seperate from
> transactional schemas. That "pain" as Mark puts it is worth a bit of
> effort.  The derivation by restriction is not an option, derivation by
> extension (with external constraints) is a good approach but one that
> would take some convincing, and using abstract / redefine would be
> good job security for the schema editors like me but not so for domain
> experts who are newer to xml schema.

Would using Schematron payload in the appinfo field to define the
derived PersonTypes make the model simpler and more directly
extensible? sorry that it's such an off the wall suggestion, but it seems
like a good question to ask at this point since the pure XMLSchema
suggestions seem to be getting pretty contrived.

i dont have an explicit recipe of *how* you would describe it in
schematron.i have only paid attention to this thread from the perspective
of the large schema design and implementation issues, so i dont know your
specific needs.

i simply tossed this out because it solved my co-occurance constraint
problem, and the more i think of it, the more convince i am that it's  a
general, albeit hacky, solution.

(thanks go to eddie and roger and jeni and probably others that i am
unaware of for pointing out this solution in the first place)

> Thanks,
> Paul Kiel
> 
> 
> 
> 
> ----- Original Message -----
> From: "Jeni Tennison" <jeni@jenitennison.com>
> To: "Paul Kiel" <paul@hr-xml.org>
> Cc: <xmlschema-dev@w3.org>
> Sent: Tuesday, April 16, 2002 12:00 PM
> Subject: Re: Schema Design: Composition vs Subclassing
> 
> 
> > Hi Paul,
> >
> > > I have a question about the effect of this best practice. It is
> > > regarding context-specific use of components. Let's take the element
> > > <Person> in a human resources context. (BTW - <Person> is too broad
> > > a concept to actually encode, this is only for discussion). We may
> > > want to use a <Person> in many contexts, where some of its
> > > components are required in one and not in another. Let's say we have
> > > two transactions of Person below (and that all children are stand
> > > alone components):
> > >
> > > Transaction 1:
> > > <Person>
> > >      <Name/><!-- required -->
> > >      <Skills/><!-- required -->
> > >      <Height/><!-- required -->
> > >      <Weight/><!-- required -->
> > > </Person>
> > > In this transaction, we need all the data about this person to do
> > > the transaction.
> > >
> > > Transaction 2:
> > > <Person>
> > >      <Name/><!-- required -->
> > >      <Skills/><!-- optional -->
> > > </Person>
> > > In this transaction, we only need a name of the person and the
> > > skills are optional. The Height and Weight have no meaning in this
> > > context and can't occur.
> >
> > None of the methods that you suggested seem particularly good to me.
> > In the example above, you have one thing that stays the same (<Person>
> > always has a <Name> element child), and two things that change
> > (whether <Skills> is required or optional, and whether the <Person>
> > includes a <Height> and <Weight>).
> >
> > If you can take advantage of treating all Person elements in the same
> > way when it comes to their Name (i.e. that you can get some code reuse
> > out of it), I'd make a general PersonType that included a <Name>
> > element:
> >
> > <xs:complexType name="PersonType" abstract="yes">
> >   <xs:sequence>
> >     <xs:element name="Name" type="xs:string" />
> >   </xs:sequence>
> > </xs:complexType>
> >
> > I'd then create types that extend this base type. For Transaction 1:
> >
> > <xs:complexType name="Transaction1PersonType">
> >   <xs:extension base="PersonType">
> >     <xs:sequence>
> >       <xs:element name="Skills" type="SkillsType" />
> >       <xs:element name="Height" type="xs:decimal" />
> >       <xs:element name="Weight" type="xs:decimal" />
> >     </xs:sequence>
> >   </xs:extension>
> > </xs:complexType>
> >
> > <xs:complexType name="Transaction2PersonType">
> >   <xs:extension base="PersonType">
> >     <xs:sequence>
> >       <xs:element name="Skills" type="SkillsType" minOccurs="0" />
> >     </xs:sequence>
> >   </xs:extension>
> > </xs:complexType>
> >
> > If you can't take advantage of the fact that the Person elements in
> > Transaction1 and Transaction2 are similar (i.e. for some reason you
> > can't share code between them) then you could design through
> > composition instead. This time the shared components should go into
> > groups:
> >
> > <xs:group name="NameGroup">
> >   <xs:sequence>
> >     <xs:element name="Name" type="xs:string" />
> >   </xs:sequence>
> > </xs:group>
> >
> > <xs:group name="SkillsGroup">
> >   <xs:sequence>
> >     <xs:element name="Skills" type="SkillsType" />
> >   </xs:sequence>
> > </xs:group>
> >
> > <xs:group name="HeightAndWeightGroup">
> >   <xs:sequence>
> >     <xs:element name="Height" type="xs:decimal" />
> >     <xs:element name="Weight" type="xs:decimal" />
> >   </xs:sequence>
> > </xs:group>
> >
> > Then you could have two (possibly anonymous) types that bring those
> > groups together as required:
> >
> > <xs:complexType name="Transaction1PersonType">
> >   <xs:sequence>
> >     <xs:group ref="NameGroup" />
> >     <xs:group ref="SkillsGroup" />
> >     <xs:group ref="HeightAndWeightGroup" />
> >   </xs:sequence>
> > </xs:complexType>
> >
> > <xs:complexType name="Transaction2PersonType">
> >   <xs:sequence>
> >     <xs:group ref="NameGroup" />
> >     <xs:group ref="SkillsGroup" minOccurs="0" />
> >   </xs:sequence>
> > </xs:complexType>
> >
> > A third possibility would be to have an abstract version of the
> > PersonType that includes a group with nothing in it as a placeholder:
> >
> > <xs:complexType name="PersonType" abstract="yes">
> >   <xs:sequence>
> >     <xs:element name="Name" type="xs:string" />
> >     <xs:group ref="PersonGroup" />
> >   </xs:sequence>
> > </xs:complexType>
> >
> > <xs:group name="PersonGroup">
> >   <xs:sequence />
> > </xs:group>
> >
> > Then, in the schema for Transaction 1, you can redefine the
> > PersonGroup group to add the required elements:
> >
> > <xs:redefine href="baseSchema">
> >   <xs:group name="PersonGroup">
> >     <xs:sequence>
> >       <xs:group ref="PersonGroup" />
> >       <xs:element name="Skills" type="SkillsType" />
> >       <xs:element name="Height" type="xs:decimal" />
> >       <xs:element name="Weight" type="xs:decimal" />
> >     </xs:sequence>
> >   </xs:group>
> > </xs:redefine>
> >
> > and similarly in the schema for Transaction 2:
> >
> > <xs:redefine href="baseSchema">
> >   <xs:group name="PersonGroup">
> >     <xs:sequence>
> >       <xs:group ref="PersonGroup" />
> >       <xs:element name="Skills" type="SkillsType" minOccurs="0" />
> >     </xs:sequence>
> >   </xs:group>
> > </xs:redefine>
> >
> > Personally, I think I'd favour 1, but I'm in the process of being
> > persuaded towards composition, so I reserve the right to change my
> > mind.
> >
> > Cheers,
> >
> > Jeni
> >
> > ---
> > Jeni Tennison
> > http://www.jenitennison.com/
> >
> >
> >
> 
> 
>

Received on Wednesday, 17 April 2002 11:41:55 UTC