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

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Restriction in XML Schema



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.