Restriction is a very important construct. I need to have a clear
understanding of its definition. There is the distance
between elegant
semantic definition and computation-oriented syntactic
definition.
My sloppy example clouded my question the first
time. (Who
does not have a personal abbreviation of such a verbose
language?;-)
Let me try again.
The base type is defined as:
<complexType name='fields'>
<sequence> <element name='field' maxOccurs='2'>
<complexType>
<attribute
name='tag'/>
</complexType>
</element> </sequence>
</complexType> Let me derive the following type:
<complexType name='myfields'>
<complexContent> <restriction base='fields'> <sequence> <element name='field'> <complexType>
<attribute name='tag' use='fixed' value='15A'/>
</complexType>
</element>
<element
name='field'>
<complexType>
<attribute name='tag' use='fixed' value='20'/>
</complexType>
</element>
</sequence>
</restriction> </<complexContent> </complexType> >From: ht@cogsci.ed.ac.uk (Henry
S. Thompson)
...
> > The definition of restriction in XML Schema reads:
> > > > >A type definition whose declarations or facets are in a > > >one-to-one relation with those of another specified type > > >definition, with each in turn restricting the possibilities > > >of the one it corresponds to, is said to be a restriction. > >Note this is an introductory summary early in the spec. This is actually Definition 2 in 2.2.1.1. Looks like the official
definition of restriction, unless someone can point to a "more"
official definition. According to this definition, my derivation
'myfields' is in error! I have to rewrite 'fields' as:
<complexType name='fields'>
<sequence> <element name='field'>
<complexType>
<attribute
name='tag'/>
</complexType>
</element> <element name='field'>
<complexType>
<attribute
name='tag'/>
</complexType>
</element> </sequence> </complexType> Of course, an elegant semantic definition we all prefer can be
( actually in "an introductory summary early in the spec"):
"...the values represented by the new type are a subset of the values
represented by the base type ..."
But this definition is not computationally feasible! It got to
be
NP-hard to compare the language sets defined by two schemas.
I am glad that you brought up the issue of Unique Particle
Attribution constraint. It is also a computational feasibility
challenge to enforce. Finding that one instance element looks
NP-Complete to me again.
I expect syntax-oriented, but more elaborate definitions
dictated by standards. Where is it? Did I lose a page in my book? :-)
Jay Zhang
IntermicsTech, Inc.
|