Re: Supporting incremental-definition of a type?

I have seen exactly this problem with a couple of my consulting clients, 
and there's no completely straightforward solution.

The approach of having an abstract schema in which everything is 
optional (minOccurs="0") and then restricting it for specific messages 
to make selected things mandatory certainly seems the right way to think 
about it. The interesting part is then how to implement the restriction 
process.

One alternative is to add constraints in the form of Schematron or XSD 
1.1 assertions (but this isn't useful if you want to use the schema for 
a message as input to a data binding tool).

I've found that when producing a "restricted" schema for specific 
message types, transforming the schema using XSLT to produce a new 
schema can be a lot simpler than defining new types derived by 
restriction from the existing types, even with the help of xs:redefine. 
Of course, transforming a schema is a lot easier if the schema is 
designed with this in mind, e.g with generous use of id attributes.

One potential way of doing this is to make the schema document take the 
form of a stylesheet:

<xsl:param name="history-is-optional" as="xs:boolean"/>

<xsl:template name="make-schema">
<xs:schema>
   ....
<xs:complexType ...>
<xs:element ref="history" minOccurs="{if ($history-is-optional) then 0 
else 1}">
        ...


I've been experimenting in Saxon with the concept of "parameterized 
schemas", in which the assertions can refer to variables/parameters 
whose values are supplied at the time a validation episode is initiated. 
It wouldn't be an inconceivable extension of this to parameterize the 
minOccurs and maxOccurs values (though at the moment, I don't know how 
to create a parameterized finite state machine to implement this idea!)

Michael Kay
Saxonica

On 11/06/2012 19:04, Matt Warden wrote:
> First, I want to say that while I have only subscribed today, I have
> already gotten a lot out of this list over the years, having ended up
> at your list archived 30 or so times to get answers to my questions.
> This is an extremely valuable resource, so thank you for the
> contributions you have all made over the years on this list. I could
> not find the answer to this question, though, which is likely because
> I don't really know what to call it.
>
> Our education data standard is made up of 1 "core" XSD, which contains
> only types and no root element, and "interchange" XSDs which include
> the core and use the types to define specific messages.
>
> As you can imagine, many of these types (like Student) are rather
> large. So far, the standard has been used to load data in batch mode,
> but we have increasingly seen interest in using it for REST style
> interfaces. As I understand the use case, if you imagine a 7-page
> wizard collecting student data, the app developer wants to be able to
> use our types in our XSD as the basis to define the messages for each
> page. But the problem is that after page one, only 1/7 of the student
> information is known, yet we have a single type called Student with
> lots of mandatory elements... elements that are collected on
> subsequent pages.
>
> The technical request we have received is to make nearly ALL elements
> optional in the types (e.g. Student) in the "core" XSD, and then
> restrict those types when they are used in specific interchanges to
> specify which elements are required.
>
> Have any of you seen this done before? Do you have alternative
> suggestions on how to accommodate this "incremental definition"
> scenario, where the application cannot possibly fill all mandatory
> elements for our type (e.g., Student) yet?
>
> Thanks for any insight,
>

Received on Monday, 11 June 2012 22:50:26 UTC