W3C home > Mailing lists > Public > xmlschema-dev@w3.org > June 2012

Re: Supporting incremental-definition of a type?

From: Andrew Welch <andrew.j.welch@gmail.com>
Date: Tue, 12 Jun 2012 09:16:28 +0100
Message-ID: <CAEG2duAm31SaewJGNPL5HgrtpygA2=LQS+8F7C-CHcZAnO8Q1g@mail.gmail.com>
To: Matt Warden <mwarden@mattwarden.com>
Cc: xmlschema-dev@w3.org
On 11 June 2012 19:04, Matt Warden <mwarden@mattwarden.com> 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?

Instead of validating on Student after page 1, could you validate
whatever subtypes you have at that point, maybe 'name', 'address' or
'id' etc. then only validate <Student> after page 7 ?



-- 
Andrew Welch
http://andrewjwelch.com
Received on Tuesday, 12 June 2012 08:23:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:20 UTC