Stylus Studio XML Editor

Table of contents

Appendices

3.10 Wildcards

Wildcards

In order to exploit the full potential for extensibility offered by XML plus namespaces, more provision is needed than DTDs allow for targeted flexibility in content models and attribute declarations. A wildcard provides for valid of attribute and element information items dependent on their namespace name, but independently of their local name.

NOTE: 
<xs:any processContents="skip"/>

<xs:any namespace="##other" processContents="lax"/>

<xs:any namespace="http://www.w3.org/1999/XSL/Transform"/>

<xs:any namespace="##targetNamespace"/>

<xs:anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/>

XML representations of the four basic types of wildcard, plus one attribute wildcard.

The Wildcard Schema Component[top]

The Wildcard Schema Component

The wildcard schema component has the following properties:

[Wildcard]

[namespace_constraint] provides for valid of attribute and element items that:

  1. (any) have any namespace or are not namespace qualified;

  2. (not and a namespace name) have any namespace other than the specified namespace name, or are not namespace qualified;

  3. (not and absent) are namespace qualified;

  4. (a set whose members are either namespace names or absent) have any of the specified namespaces and/or, if absent is included in the set, are unqualified.

[process_contents] controls the impact on assessment of the information items allowed by wildcards, as follows:

strict

There must be a top-level declaration for the item available, or the item must have an xsi:type, and the item must be valid as appropriate.

skip

No constraints at all: the item must simply be well-formed XML.

lax

If the item, or any items among its [children] if it's an element information item, has a uniquely determined declaration available, it must be valid with respect to that definition, that is, valid where you can, don't worry when you can't.

See [Annotations] for information on the role of the [w-annotation] property.

XML Representation of Wildcard Schema Components[top]

XML Representation of Wildcard Schema Components

The XML representation for a wildcard schema component is an [any] or [anyAttribute] element information item. The correspondences between the properties of an [any] information item and properties of the components it corresponds to are as follows (see [complexType] and [attributeGroup] for the correspondences for [anyAttribute]):

A particle containing a wildcard, with properties as follows (unless minOccurs=maxOccurs=0, in which case the item corresponds to no component at all):

[The Particle Schema Component] [The Wildcard Schema Component]

Wildcards are subject to the same ambiguity constraints ([Unique Particle Attribution]) as other content model particles: If an instance element could match either an explicit particle and a wildcard, or one of two wildcards, within the content model of a type, that model is in error.

Constraints on XML Representations of Wildcards[top]

Constraints on XML Representations of Wildcards Wildcard Representation OK

In addition to the conditions imposed on [any] element information items by the schema for schemas, the corresponding particle and model group must satisfy the conditions set out in [Constraints on Model Group Schema Components] and [Constraints on Particle Schema Components].

Wildcard Validation Rules[top]

Wildcard Validation Rules Item Valid (Wildcard)

For an element or attribute information item to be locally valid with respect to a wildcard constraint its [namespace name] must be valid with respect to the wildcard constraint, as defined in [Wildcard allows Namespace Name].

When this constraint applies

  1. if[process_contents] is lax

    thenthe item has no context-determined declaration with respect to [Assessment Outcome (Element)], [Schema-Validity Assessment (Element)] and [Schema-Validity Assessment (Attribute)].

  2. if[process_contents] is strict

    thenthe item's context-determined declaration is mustFind.

  3. if[process_contents] is skip

    thenthe item's context-determined declaration is skip.

Wildcard allows Namespace Name

For a value which is either a namespace name or absent to be valid with respect to a wildcard constraint (the value of a [namespace_constraint])

  1. The constraint must be any.

    1. The constraint is a pair of not and a namespace name or absent (call this the namespace test).

    2. The value must not be identical to the namespace test.

    3. The value must not be absent.

  2. The constraint is a set, and the value is identical to one of the members of the set.

Wildcard Information Set Contributions[top]

Wildcard Information Set Contributions

None as such.

Constraints on Wildcard Schema Components[top]

Constraints on Wildcard Schema Components

All wildcards (see [Wildcards]) must satisfy the following constraint.

Wildcard Properties Correct

The values of the properties of a wildcard must be as described in the property tableau in [The Wildcard Schema Component], modulo the impact of [Missing Sub-components].

The following constraints define a relation appealed to elsewhere in this specification.

Wildcard Subset

For a namespace constraint (call it sub) to be an intensional subset of another namespace constraint (call it super)

  1. super must be any.

    1. sub must be a pair of not and a namespace name or absent.

    2. super must be a pair of not and the same value.

    1. sub must be a set whose members are either namespace names or absent.

      1. super must be the same set or a superset thereof.

      2. super must be a pair of not and a namespace name or absent and that value must not be in sub's set.

Attribute Wildcard Union

For a wildcard's [namespace_constraint] value to be the intensional union of two other such values (call them O1 and O2):

  1. ifO1 and O2 are the same value

    thenthat value must be the value.

  2. ifeither O1 or O2 is any

    thenany must be the value.

  3. ifboth O1 and O2 are sets of (namespace names or absent)

    thenthe union of those sets must be the value.

  4. ifthe two are negations of different namespace names

    thenthe intersection is not expressible.

  5. ifeither O1 or O2 is a pair of not and a namespace name and the other is a set of (namespace names or absent)

    then

    1. ifthe set includes the negated namespace name

      thenany must be the value.

    2. ifthe set does not include the negated namespace name

      thenwhichever of O1 or O2 is a pair of not and a namespace name must be the value.

In the case where there are more than two values, the intensional intersection is determined by identifying the intensional intersection of two of the values as above, then the intensional intersection of that value with the third (providing the first intersection was expressible), and so on as required.

Attribute Wildcard Intersection

For a wildcard's [namespace_constraint] value to be the intensional intersection of two other such values (call them O1 and O2):

  1. ifO1 and O2 are the same value

    thenthat value must be the value.

  2. ifeither O1 or O2 is any

    thenthe other must be the value.

  3. ifeither O1 or O2 is a pair of not and a namespace name and the other is a set of (namespace names or absent)

    thenthat set, minus the negated namespace name if it was in the set, must be the value.

  4. ifboth O1 and O2 are sets of (namespace names or absent)

    thenthe intersection of those sets must be the value.

  5. ifthe two are negations of different namespace names

    thenthe intersection is not expressible.

In the case where there are more than two values, the intensional intersection is determined by identifying the intensional intersection of two of the values as above, then the intensional intersection of that value with the third (providing the first intersection was expressible), and so on as required.