Re: Defining recursive elements?

This is all great information - thanks.  It does go against most of
what I've read recently on the pros and cons of the various styles....

>From all the replies I've read, the preferred pattern appears to be
the original "all globals" approach (unfortunately called salami slice
elsewhere), with the adviso that the root element can be application
defined.



On 5/17/07, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com> wrote:
> Andrew Welch writes:
>
> > With global definitions some documents will be valid that you might
> > not want, for example an XML document of just <header/> would validate
> > using that schema.
>
> That's a bit of an oversimplification.  The schema recommendation says the
> following about the ways in which a schema may be used to validate an
> instance document [1]:
>
> -------------
> With a schema which satisfies the conditions expressed in Errors in Schema
> Construction and Structure (§5.1) above, the schema-validity of an element
> information item can be assessed. Three primary approaches to this are
> possible:
> 1 The user or application identifies a complex type definition from among
> the {type definitions} of the schema, and appeals to Schema-Validity
> Assessment (Element) (§3.3.4) (clause 1.2);
> 2 The user or application identifies a element declaration from among the
> {element declarations} of the schema, checks that its {name} and {target
> namespace} match the [local name] and [namespace name] of the item, and
> appeals to Schema-Validity Assessment (Element) (§3.3.4) (clause 1.1);
> 3 The processor starts from Schema-Validity Assessment (Element) (§3.3.4)
> with no stipulated declaration or definition, and either ·strict· or ·lax·
> assessment ensues, depending on whether or not the element information and
> the schema determine either an element declaration (by name) or a type
> definition (via xsi:type) or not.
> -------------
>
> If you choose to use a processor that implements the third option, then
> your statement is correct.  If you want to ensure that the root element is
> "component", then you should get a processor that implements option #2,
> and designate the declaration for element "component" as the one from
> which validation is to start.
>
> By the way, among the reasons that option 3 is provided, is to facilitate
> the creation of incremental validators.  Let's say you have an editor
> that's helping you enter these documents.  Even though you want the
> document as a whole to be rooted at <part>, it's possible that you are
> editing a "header".  Rule 3 allows such an editor to revalidated just the
> <header> element as it is changed, even though it is not the root of the
> document.
>
> Noah
>
> [1] http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/#validation_outcome
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>

Received on Friday, 18 May 2007 08:36:30 UTC