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

RE: Schema Design: Composition vs Subclassing

From: Mark Feblowitz <mfeblowitz@frictionless.com>
Date: Tue, 23 Apr 2002 13:36:59 -0400
Message-ID: <4DBDB4044ABED31183C000508BA0E97F040ABA69@fcpostal.frictionless.com>
To: "'Eddie Robertsson'" <erobertsson@allette.com.au>
Cc: "'John Utz'" <utz@singingfish.com>, Paul Kiel <paul@hr-xml.org>, xmlschema-dev@w3.org, "Henry S. Thompson" <ht@cogsci.ed.ac.uk>
(Sorry for the delay - been a bit busy...)

Do you think it would be helpful to have the Schematron context decided by
the
context in where it's declared in the XML Schema?

Now there's a question. 

So many things to consider. Locally versus globally specified/scoped
constraints; co-occurrence constrains, where to place a context-sensitive
constraint and how to understand/interpret its semantics, ...

Such a mechanism could do more harm than good. Trying to debug constraints
that have a built-in assumption of context could be quite a challenge,
unless the semantics were clean, obvious, uniform, and predictable.

If there was such a mechanism, it would be best if the context could be
referenced from within the XPath expression (e.g., referring to "." within
the expression).

Most important is how usable the constraint language is, and how well it is
integrated with Schema. Ideally I'll like to see a constraint language that
it fits into schema, rather than one that's stuffed into the appinfo. And
that should probably be a guiding principle: design a constraint language as
it would be incorporated into Schema - and then determine how it could
(temporarily) implemented as living within - and extracted from - appinfo.

As I said in my original posting, though, collocation of constraints could
be problematic, if there is a need for separate constraint sets. It wouldn't
matter to me that the constraints are context-sensitive, if I needed to keep
several sets separate from the schema file. Then I'd just resort to
expressing the context in the XPath of each constraint and be done with it.

Mark

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

 -----Original Message-----
From: 	Eddie Robertsson [mailto:erobertsson@allette.com.au] 
Sent:	Wednesday, April 17, 2002 7:52 PM
To:	Mark Feblowitz
Cc:	'John Utz'; Paul Kiel; xmlschema-dev@w3.org; Henry S. Thompson
Subject:	Re: Schema Design: Composition vs Subclassing

Hi Mark,

> FWIW, the fact that a Schematron constraint is co-located doesn't reduce
the
> amount you have to express in the constraint itself - the constraint
doesn't
> know where it was extracted from, so it's location in the schema has no
> bearing on the scope  of the rule. You have to state that explicitly.

When I wrote the original XSD2Schtrn.xsl stylesheet my first thought was to
only
declare the Schematron constraints on the assertion level instead of the
rule
level. This would mean that the context of the appinfo in the XML Schema
would
decide what the context attribute would be for the Schematron rule. I
abandoned
this solution mainly due to the following reasons:

1) My XSLT skills are limited (which showed when Francis rewrote and
simplified
my original script) and having the stylesheet determine the context would
add
more complexity to the stylesheet.

2) I think this would have been too limited. For example, I've found that in
many cases it's very useful to include predicates to determine the context
of
rule or to decide whether the rule should be applied only to one instance of
a
particular element or all elements with this name in the document.

Do you think it would be helpful to have the Schematron context decided by
the
context in where it's declared in the XML Schema?

Cheers,
/Eddie

> We toyed with the prospect of putting the constraints in appinfo and
decided
> to store them separately, mainly for configuration management purposes. We
> wanted to be able to change the constraints (or add new ones) without
> rev'ing the rest of the definition. With co-located constraints, the user
> can't tell which part of the xsd has changed.
>
> 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:   John Utz [mailto:utz@singingfish.com]
> Sent:   Wednesday, April 17, 2002 11:41 AM
> To:     Paul Kiel
> Cc:     xmlschema-dev@w3.org; Henry S. Thompson
> Subject:        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 Tuesday, 23 April 2002 13:38:16 GMT

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