W3C home > Mailing lists > Public > xmlschema-dev@w3.org > May 2011

RE: ANN: Algorithm for Merging a simpleType Dependency Chain

From: Costello, Roger L. <costello@mitre.org>
Date: Sun, 1 May 2011 10:11:34 -0400
To: "xmlschema-dev@w3.org" <xmlschema-dev@w3.org>
Message-ID: <9E51F88D5247B648908850C35A3BBB50053EE989C6@IMCMBX3.MITRE.ORG>
Hi Mukul,

No, I am not merely bundling together all the facets into a simpleType. Rather,  I am intelligently merging/consolidating/assimilating the facets. 

Example: BostonSurfaceAreaElevation has a base type, EarthSurfaceElevation

<xsd:simpleType name="BostonAreaSurfaceElevation">
      <xsd:restriction base="elev:EarthSurfaceElevation">
                  <xsd:minInclusive value="0"/>
                  <xsd:maxInclusive value="120"/>

<xsd:simpleType name="EarthSurfaceElevation">
    <xsd:restriction base="xsd:integer">
        <xsd:minInclusive value="-1290"/>
        <xsd:maxInclusive value="29035"/>

I wish to create a single, standalone rendering for BostonAreaSurfaceElevation. That is, a representation that does not depend on a base type. We can see that 

    <xsd:minInclusive value="0"/>


    <xsd:minInclusive value="-1290"/>

Ditto for maxInclusive.

Thus, merging yields this single, standalone rendering for BostonAreaSurfaceElevation

<xsd:simpleType name="BostonAreaSurfaceElevation">
      <xsd:restriction base="xsd:integer">
                  <xsd:minInclusive value="0"/>
                  <xsd:maxInclusive value="120"/>

It is easier to deal with this, than it is to deal with a dependency chain, particularly if the types are scattered across many files and are in many namespaces.

Thanks for the questions Mukul. Apparently my paper needs clarification.


-----Original Message-----
From: Mukul Gandhi [mailto:gandhi.mukul@gmail.com] 
Sent: Sunday, May 01, 2011 5:50 AM
To: Costello, Roger L.
Cc: xmlschema-dev@w3.org
Subject: Re: ANN: Algorithm for Merging a simpleType Dependency Chain

Hi Roger,
    The thing which confuses me, within your article is that you use
the terminology, xsd:value (i.e the component "value" is in XML Schema
namespace, whereas in XML Schema language we currently don't have any
component named "value" within the xsd: namespace). So how would we
process such a component with a compliant XML Schema processor?

May be you've assumed that "if the component xsd:value existed -- even
if it doesn't exist currently".

There's another observation I could make about this topic (as follows),

It seems you're trying to create a single (a kind of monolithic, if we
can say so) type definition from an existing chain of simpleType
definitions. In this newly rendered simpleType component, all the
constraints of the participating types are present. This seems to me
like an opposite of re-factoring. I doubt if this approach may find
general purpose uses.

On Sun, May 1, 2011 at 2:45 PM, Costello, Roger L. <costello@mitre.org> wrote:
> Hi Mukul,
> Recall the purpose of my algorithm: create a single, standalone rendering of a simpleType.
> By sticking to the XML Schema representation of simpleTypes it is impossible to create a single, standalone rendering of a simpleType. Why? Because of the pattern facet - pattern facets within a simpleType are or-ed together whereas pattern facets across a dependency chain are and-ed together.
> Therefore, I must create my own rendering. In my rendering all facets are and-ed together. Thus, I rendered enumeration facets as shown below (thanks for Michael Kay for this rendering of enumeration).
> /Roger

Mukul Gandhi
Received on Sunday, 1 May 2011 14:12:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:15:59 UTC