W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structureswd-20091203W3C Working Draft3December2009http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/XMLXHTML with changes since version 1.0 markedXHTML with changes since previous Working Draft markedIndependent copy of the schema for schema documentsIndependent copy of the DTD for schema documentsIndependent tabulation of components and microcomponentsList of translationshttp://www.w3.org/TR/xmlschema11-1/http://www.w3.org/TR/2009/CR-xmlschema11-1-20090430/Shudi (Sandy) Gao 高殊镝IBMsandygao@ca.ibm.comC. M. Sperberg-McQueenBlack Mesa Technologies LLCcmsmcq@blackmesatech.comHenry S. ThompsonUniversity of Edinburghht@inf.ed.ac.ukHenry S. ThompsonUniversity of Edinburghht@inf.ed.ac.ukNoah MendelsohnIBMnoah_mendelsohn@us.ibm.comDavid BeechOracle Corporation (retired)davidbeech@earthlink.netMurray MaloneyMuzmo Communicationsmurray@muzmo.com
This section describes the status of this document at the
time of its publication. Other documents may supersede this document.
A list of current W3C publications and the latest revision of this
technical report can be found in the
W3C technical reports index at
http://www.w3.org/TR/.
This
W3C Last Call Working Draft
specifiestheW3C XML Schema Definition Language (XSD) 1.1. It
is here made
available for review by W3C members
and the public.
XSD 1.1 retains all
the essential features of XSD 1.0, but adds several new
features to support functionality requested by users,
fixes many errors in XSD 1.0,
and clarifies wording.
This draft was published
on 3 December 2009.
The major revisions since the previous
public working draft
include
the following:
Group references are now allowed in
<xs:all> model groups.
Such
references must have minOccurs=maxOccurs=1 and must refer
to other <xs:all> groups.
(This change
resolves issue
7031 XSD 1.1 doesn't support conversion of xs:sequence to xs:all
because xs:all can't contain groups references.)
The definition of conformnance classes in section
has been clarified.
The usage of validation,
, and related terms has been clarified
and made more consistent.
A bug in the definition of the has been fixed.
The rules regarding the default behavior of open content have
been changed. The XML mapping rule (in
) has been adjusted to
provide more graceful behavior when default open content is
specified and open content is also inherited from a type
being extended; in that case, the union of the two open content
wildcards is now taken.
Several editorial corrections and improvements have been made.
For those primarily interested in the changes since version 1.0,
the appendix is the recommended starting
point. It summarizes both changes made
since XSD 1.0 and some changes which were expected (and predicted
in earlier drafts of this specification) but have not been made
after all.
Accompanying versions of this document display in color
all changes to normative text since version 1.0 and since the
previous Working Draft.
The Last Call
review period
for this document extends until 31 December 2009.
Comments on this document should be made in
W3C's public installation of Bugzilla,
specifying "XML Schema" as the product.
Instructions can be found at
http://www.w3.org/XML/2006/01/public-bugzilla.
If access to Bugzilla is not feasible,
please send your comments to the W3C XML Schema comments mailing list,
www-xml-schema-comments@w3.org
(archive)
Each Bugzilla entry and email message should contain only one comment.
Although feedback based on any
aspect of this specification is welcome, there are certain aspects of
the design presented herein for which the Working Group is
particularly interested in feedback. These are designated
priority feedback aspects of the design, and
identified as such in editorial notes at appropriate points in this
draft.
Any feature
mentioned in a
priority feedback note is a feature
at risk: the feature may be retained as
is or
dropped, depending on the feedback received from readers,
schema authors, schema users, and implementors.
Publication as a
W3C Working Draft
does not imply endorsement by the
W3C Membership. This is a draft document and may be updated, replaced
or obsoleted by other documents at any time. It is inappropriate to
cite this document as other than work in progress.
The
W3C XML Schema Working Group
intends to request advancement of this specification
and publication as a
Proposed Recommendation(bypassing
the usual Candidate Recommendation phase)
as soon after 31 December 2009 as the following
conditions are met.
A test suite is available which tests each required and optional
feature of XSD 1.1.
Each feature of the specification has been implemented successfully
by at least two independent implementations.
The Working Group has responded formally to all issues raised
against this document during the Candidate Recommendation period.
The expected Proposed Recommendaton
may include editorial changes and may possibly remove features
identified in this draft as being at risk.
At the time this Last Call Working Draft
was published, no interoperability
or implementation report had yet been prepared.
This document has been produced by the
W3C XML Schema Working Group
as part of the W3C XML
Activity. The goals of
XSD 1.1 are
discussed in the documentRequirements
for XML Schema 1.1.
The authors of this document are
the members of the XML Schema Working Group. Different parts of this
specification have different editors.
This document was produced by a group operating under the 5 February
2004 W3C Patent Policy. W3C maintains a public list of
any patent disclosures made in connection with the deliverables
of the group; that page also includes instructions for disclosing a
patent. An individual who has actual knowledge of a patent which the
individual believes contains Essential
Claim(s) must disclose the information in accordance with
section
6 of the W3C Patent Policy.
The English version of this specification is the only normative
version. Information about translations of this document is available
at http://www.w3.org/2003/03/Translations/byTechnology?technology=xmlschema.
This
document specifies the XML Schema Definition Language,
which offers facilities for describing the structure and constraining the contents
of XML documents, including those which
exploit the XML Namespace facility. The schema language, which is itself
represented in
an XML vocabulary and uses
namespaces, substantially reconstructs and considerably
extends the capabilities found in XML
document type definitions (DTDs). This specification depends on
XML Schema Definition Language 1.1 Part 2: Datatypes.
Edinburgh, et al.: World-Wide Web Consortium, XML Schema
Working Group, 2004.
Created in electronic form using XML, starting from [internal draft
of] XML Schema Part 1: Structures, Second Edition.
EnglishExtended Backus-Naur Form (formal grammar)Extensible Markup Language (XML)Changes between XSD 1.0 2e and 1.0 3e not otherwise
labeled. (Bug fixes should be labeled appropriately; this is for
things like changing 'Second edition' to 'Third edition'.)Changes between XSD 1.0 and XSD 1.1, marked
retrospectively to allow 1.1 tool chain to produce 1.0 document.
Changes between XSD 1.0 and XSD 1.1, marked
retrospectively to allow 1.1 tool chain to produce 1.0 document,
which even diff-1.0 should treat as silent.
For changes, see CVS change log at the end of the document.
For marked diff groups, see the following items.Changes made (and with very few exceptions
marked as such) in the first public working draft of July 2004.
Mostly approved 2005-02-18. (What wasn't approved is now
tagged ep01.)Minor typos and corrections made by MSM; these
will be batched together and handled in an editorial change
proposal. Approved as part of EP-06, 2005-02-18.Changes to the section on import (mostly —
some go beyond import to the rest of the section), based on
NM's proposal in Brisbane. Approved as EP-07, 2005-02-18.Non-status-quo draft changes to implement
Brisbane partial consensus wrt RQ-17.
Discussed 2005-02-18, into WD as non-status-quo text.
Changes originally part of rq17 abandoned when
MSM revised the RQ-17 proposal 30 Oct 2006.
Additional changes to fix links broken by rq17.
Not discussed 2005-02-18, but into WD anyway as non-status-quo text
(because otherwise links are broken).
Changes to attribute restriction in complex types
and attribute group redefinition.
Another way to change attribute restriction.
Abandoned text for RQ-17 attribute restriction.
Auxiliary diff group for RQ-17. Has no independent
value; its sole purpose is to make the output valid when diff group
rq17 and rq17a are not adopted. Display as 'pre' iff rq17 is pre,
otherwise display as 'post'.
Added 2005-02-19. Needs no discussion or approval; it's just
an artifact of our diff system.
Draft rough wording (not status quo) for RQ-144.
Discussed 2005-02-18, into WD as non-status-quo text.
This is bug 2822; cf. bug 2846=RQ-142.
Approved 2006-08-04.
Replacement wrapper (after rq144 became
status quo).
(2006-09-28: rq144-wrap2 appears to have no instances except its
explanation.)Fixes to broken links caused by diff group rq144.
Not discussed 2005-02-18, not sure what to do. This should go
together with rq144sc (schema construction variations).
Approved 2006-08-18.
Sub-part of RQ-144: no variation in PSVI.
Approved 2006-08-04.Sub-part of RQ-144: schema construction variations.
Approved 2006-08-18.Sub-part of RQ-144: fallback variation.Sub-part of RQ-144: psvi flavors.Sub-part of RQ-144: schema invocation details.Sub-part of RQ-144: conformance clauses.
Approved 2006-08-04.Auxiliary diff group for RQ-144. Has no
independent value; its sole purpose is to make the output document valid
with or without rq144. Display as 'pre' iff rq144 is pre;
otherwise display as 'post'.
Added 2005-02-19. Does not need WG discussion or approval; it's
just a mechanism for controlling the diff and the markup.
Changes made by WG in RQ-144 during meetings of
4 and 18 August.'New Orleans' changes requested by WG in RQ-144
and approved in advance by a 'New Orleans' vote, during meetings of
4 and 18 August.Changes made by WG in RQ-144 during ftf meetings of
21-23 18 August.Deletions to RQ-144 proposal agreed on by WG
during ftf meetings of 21-23 18 August.An editorial proposal prepared by MSM.
Eliminate nested modals, to avoid entailing modal logic.
Check all occurrences of 'must', 'may', and 'should', eliminate
where not aligned with RFC 2119. (Not entirely successful; I
eliminated almost all non-2119 occurrences of 'may', but not of
'should'.)
Partly approved 2005-02-18 as EP-08, partly postponed. Postponed bits
('may') retagged as diff group 'may'.
Originally part of "modals". Split off 2005-02-18
after HT and MSM were unable to agree on specific cases; to be taken
up again later.
Proposed amendments to EP-06 (2005-02).
Approved 2005-02-18.Proposed amendments to EP-08 (2005-02).
Approved 2005-02-18.Diff group for changes related to micro-components
(were originally tagged fpwd). Split off from fpwd 2005-02-18.Misnamed for split-off addition of Scope to CTD --
overtaken by context-2338.Diff group for changes related to anyAtomicType
(were originally tagged fpwd). Approved 2005-02-18.Other last-minute fixes for WD 2 (2005-02).Changes which we record for the sake of
the audit trail but which are not to be shown colored in WD 2 (2005-02).Dummy diff group for sample non-status-quo text.Change markup which we decided against, but
which for whatever reason (sentimentality, or a suspicion that
we might change our minds back, or just a hope we will) we do
not wish to delete. Yet.Selective change of "if" to "if and only if"
(and other attempts to make sentences with "if" clearer).Changes of "if"/"then" related to RQ-144 (and thus
possibly more controversial than those of "iff").Changes of "is" to "may" related to RQ-144 (and thus
distinct in impact from those of "iff.144").
(2006-07-26: N.B. the opt.144 changes reflect the proposition that
what is in the PSVI is always / must be exposed by a conforming
validator. The WG seems to have moved firmly to the opposing
view, that all PSVI properties are always present, and an
implementation does or doesn't expose them. As a result, the
opt.144 changes look like an utter disaster. Do NOT try turning
them on!)Reverted changes formerly marked iff.144.
Agreed 15 April 2005 (http://www.w3.org/2005/04/15-xmlschema-minutes.html#item10),
22 April (http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2005Apr/0056.html).
(! 2006-09-28 this diff group appears not to have any members)
Changes to reconcile overlap/conflict between parts 1 and 2Changes to reconcile overlap/conflict between parts 1
and 2 in the XML<->component mapping rulesChanges in tableaux for simple type definition to align with
part 2, as agreed in Edinburgh.
(These could be folded into rec12-map, probably, but
I'm making them separate just out of caution. -MSM)A paragraph added by std-1915 that was
moved by b3251 / b5152-std. Old location, as add.A paragraph added by std-1915 that was
moved by b3251 / b5152-std. New location, as add.Deletion of scope property in tableau for anySimpleType.
This change was made as part of / at the same time as std-1915, but since
scope was added after 1.0, it needs to be treated separately to get the colors
in the diffs to come out right.Remove dependency on canonical forms.
N.B. some apparent errors in this diff group corrected
silently by MSM, 2009-07-21.
Second pass on RQ-129, to implement WG instructions
of 2006-02-17 (no real need for this to be separate from rq129
except that I'm uncertain about these changes and want to be able
to roll them back easily)Additional pass to implement WG instructions
of 2006-02-17 within nsq RQ-17 text.
This does need to be separate from rq129.Material apparently mistagged when rq129 was
first prepared, now re-tagged. This should be 'pre'.Implement RQ-120, use 'derived' consistently
vis a vis 'constructed'Implement fix for R-96, bug in scope when decl is
inside group defnFix for R-180, bug 1892. (The entry for 1892 says
it's 1.0 only, but the text is the same in 1.0 and 1.1, so I'm putting
this fix in here.)Late amendments to the omnibus proposal which
included both 1913 and 1915. Approved by WG 16 December 2005.Health warning about white space normalization,
approved at Toronto ftf meeting (according to bug 2532 - I seem to have
read past it when processing the Toronto minutes).Bug 2333 (= R-198, union of unions). Changes to
eliminate flattening of unions to make them contain only atomic and list
types. This requires changing the description of [member type
definition] and friends; three designs are sketched, labeled b2333a,
b2333b, and b2333c.Bug 2333 (= R-198, union of unions). One way to
handle member type definition properties in the PSVI.
Make [member type definition] refer to the ground (bottom-level)
atomic or list type to which a value was ultimately assigned.
Cost: constraints imposed by other types in the derivation chain
are not visible. Cost: if the same ground type appears more than
once in the membership tree, we cannot know which appearance we are
dealing with. (This is already true in 1.0. But in 1.0, when
restrictions on sub-unions are lost, what difference can it
make which appearance we have?)Bug 2333 (= R-198, union of unions). Second way to
handle member type definition properties in the PSVI. Make [member
type definition] contain a sequence of type definitions (beginning
with the immediate member of the declared type and ending with the
non-union, i.e. atomic or list type) to which the value was ultimately
assigned. Cost: change to component structure will disturb some WG
members. Cost: the properties [member type definition name],
[member type definition namespace], and [member type definition
anonymous] become kind of clumsy. (Our own damn fault for not
defining structures for expanded names.)Bug 2333 (= R-198, union of unions). Third way to
handle member type definition properties in the PSVI.
Bite the bullet: make [member type definition] refer to the primitive
type to which a value was ultimately assigned.
Cost: constraints imposed by other types in the derivation chain
are not visible. Cost: change in component semantics will disturb
some WG members. Cost: if the same primitive type appears several
times in the membership tree, it won't be clear which intermediate
unions were involved.Priority feedback request for fix
2333. Drafted by MSM 2006-01-27, not status quo until the
other editors review and agree.Priority feedback request added
by 2333, moved by 3251. Old location, as add.Priority feedback request added
by 2333, moved by 3251. New location, as add.Changes for Bugzilla 1838 = RQ-152 = support for XML
1.1.Changes to bibref elements, in connection with
1838. Tagged retrospectively (2009-07-17) to allow XSD 1.0
reconstructions to continue to generate short ref form "XML 1.0
(Second Edition)" and current spec to continue to say "XML 1.0".
The generic references to ref-xml and ref-xml-namespaces have
been eliminated (although an editorial proposal will soon
re-introduce them).
End-game resolution of dangling inconsistencies between
parts 1 and 2Text movement in eg-1852. Added by MSM; I have
not done anything like a systematic search, but happened to notice that
the definition of key-baseTypeDefinition had moved and was marked as a
deletion in old location but not as an insertion in new one. The
eg-1852-silent diff group is to hold the insertion. Mark it either pre
or post, not colour, so that the micro-changes can be seen.Added in rec12-main, but deleted in eg-1852Add {context} property to CTDsRevert an ep01 change per WG requestSeparate out content-model aspect of
restriction-is-subsumption for separate considerationIntroduce simple weakened wildcards, resolving
Bugzilla 3519. This proved to require more work than had been
expected, because the existing UPA appears not to be an
effective concept. The group "ww-all" is used as an umbrella
for several smaller changes: ww-LM, ww-p, and ww.Auxiliary proposal, preparatory setup for ww / 3519.
Introduces the notion that particles denote languages and
introduces the notation L(P) for the language accepted by
particle P.Auxiliary proposal, preparatory setup for ww / 3519.
Introduces the notions of path and competition between particles.
Introduce simple weakened wildcards. This group
has the core change, making UPA allow competition between element
declarations and weakened wildcards.
IN ITS CURRENT STATE, IT DEPENDS CRUCIALLY ON GROUPS "ww-LM" AND "ww-p".Speculative / experimental text for ww / 3519.
(At the moment, it's used for text which hasn't yet been classified
as ww-LM, ww-p, or ww.)
Changes asked for by the WG at the ftf of 2006-08.cleanup included in Runtime EDCRuntime EDCRuntime EDC option #3Runtime EDCRuntime EDC disallow type changeRemove stuff from earlier drafts or editorial
notes that no longer apply.Some changes where it was easier to change
the diff group name than to comment them out. Delete them eventually;
for now I save them in case I get cold feet about their replacements,
and want these bits back.Phrases in status section which apply only to
to WG-internal draft copies.Material (in status section and possibly elsewhere)
which applies only to change proposals.Literate programming change: make the master source of
the schema for schemas live in this document, not elsewhere.
This was finally incorporated into dg-approved in 2006-03.
Addition of ptd, itd, and mtd to display
for simple type definitions. This happened after the WD of 200502 and should
be marked as an add vis-a-vis that WD and vis-a-vis 1.0.SOTD prose for the draft of March 2006.Last-minute editorial changes prior to publication
of March 2006.Partial resolution of bug 2506, relax constraints
on 'all' groups. Drafted by SG, transcribed here by MSM.Another proposal for bug 2506: allow extension of
'all' groups to be 'all' groups. Drafted by SG as part of his proposal,
but separated here because it's lacks phase-1 consensus. Revised by
MSM 2006-09-28.A deletion by b2506-2 that needs to be
separate, to allow 1.0 to accept the deletion.Another proposal for bug 2506: allow 'all' groups to be
appear in 'sequence' or 'choice' groups.Editorial proposal to tag all component references
not currently tagged.
attribute (declaration).
element (declaration).
complex type (definition).
attribute use.
attribute group (definition).
model group.
named model group.
x particle done 2006-07-24.
wildcards
identity-constraint (definition)
notation (declaration)
annotation
simple type definition
Preliminary changes for versioning mechanism v-m3:
fallback to declared type. Editorial changes, no substantive changes
here.
To be merged with the rest of vm3. To remove some text added by vm3-0.
Proposal for versioning mechanism v-m3: fallback to
declared type. Will probably rely on vm3-0.Words I have tried to draft, but
wasn't satisfied with. Saved in case I want to try again.
Delete these later. (2006-10-11)
To be merged with the rest of vm3. To remove some text added by vm3-1.
Sandy's changes to vm3.
Sandy's extra changes not directly related to vm3.
MSM's changes of 29 October, late tweaks and changes to the proposal.
More on "fallback to declared type". Use context-determined type for
unexpected elements.
Fix a bug in definition of governing element declaration.
Bug 2861, co-constraints as check clauses,
part / level 1.MSM's modifications to SG's 2861 proposal;
mostly kept separate to make them easier to roll back, but
some changes in ednotes etc. not separated.Changes made based on WG's feedback from 08/2006
f2f meetings.To support assertions in named (attribute)
groups. Rejected at 08/2006 f2f meeting.To support mixed content in assert/report
elements.To carry assertions in particles.
Rejected at 08/2006 f2f meeting.Changes to XPath subset.Negative wildcards, part 1.Changes made based on WG's feedback from 08/2006
f2f meeting.Negative wildcards, part 2.Negative wildcards fixes.Correct descriptions of [element declaration]
and [type definition] PSVI properties.Text movement for 3714.Annotation cluster.Additional annotation changes.MSM's proposed modifications to
bannotations and bannotations-1. May be merged into them
once we have editorial agreement; they are distinct only
to make it easier to roll them back.Float up annotations on attribute
group references.Change annotation attributes to a set.Expose actual values in PSVI.Minor fixes to PSVI subsets.(was once ed18-errors) A proposal to resolve bug
3573 by revising the one place where we deviate violently from the
rule that behavior of conforming processors in the face of errors is
out of scope.Keep namespace the same, add text.Expose the governing declaration and
governing type definition, whether the item is valid or not.Fixes for some errors in the weakened wildcard
proposal.Proposal to eliminate the use of the term
"context-determined declaration" for the keywords mustFind,
skip and undefined. Begun 2006-10-09.Material inserted by b3714 and
now deleted again (mostly to be tagged as termdefs).
Begun 2006-10-09. Finished 2006-10-12, with SG's changes
integrated.Continuation of b3725, separate diff group
to allow us to decide later whether to present as one or as two
proposals. This part replaces the term 'Test' as in Test[ES,P] with
the concept of a complex type binding its
dependents. Begun 2006-10-09, finished 2006-10-12; SG's
changes integrated.Material inserted by b3725 and
now deleted again by rq146, which moves the material to a different
section. Currently marked as 'add'. If/when you change to 'del',
then (a) change the ID, (b) correct the disposition files, and
(c) change key-dft-binding to del_key-dft-binding, and
add_key-dft-binding to key-dft-binding.
Begun 2006-10-10. Elaborated 2006-10-20 by MSM, trying to
solve broken links.A group of cleanup changes, gathered together
in the hopes that all will be non-controversial.
Bug 2829 RQ-156 Outlaw complex types with mixed simple content (mixedSimple).
To expose member type definitions for list of unions.
To pick up a stray erroneous 'must' in a description of the PSVI.
PSVI fixes for values and member type definitions.
Easier restriction with local targetNamespace.
Mark local targetNamespace as feature at risk.
Changes approved on the 'consent agenda'
at the meeting of 2006-10-20. Issues 2235, 2328, 2857, 2866, 2956.
Open content in complex types.
Open content in complex type restriction. Don't need additional rules because
the updated "attribution" and "default binding" definitions covered this case.
Part of original vm13 proposal. Don't apply anymore given the new syntax.
Amendments and new syntax.
Suggestions from WG members on VM13.
Make "any" under "openContent" optional.
Move stuff added earlier by 3725.
Move stuff added earlier by b3714-movement.
Move stuff added earlier by ww-p.
Not-in-schema wildcards.
Back out changes to wildcard constraints (negative wildcard)
as a result of adopting vm19.
To replace occurrences of "intensional" with "wildcard".
Tentative revisions to vm19-1.
Tentative revisions to vm19-3.
Material added by b2867-1 and deleted by vm19-3.
Clean up.
IDC cluster.
Additional IDC changes for skip and nil.
Changes approved on the 'consent agenda'
at the meeting of 2006-10-27.
Conditional type assignment.
Rough draft done 29 Oct 2006, in haste and by a
tired editor.
Present different Conditional type assignment proposals.
Use Cartesian product to inherit type selections. Also includes
Revisions suggested by Fabio Vitali.
Check type selections from base types at runtime.
Changes originally part of cta-rt-xx that are no longer wanted,
but which I haven't had the courage to delete outright.
Require type selection of base element be a prefix of that of derived.
Just check the declared type (st = 'static typing').
Changes common to CTA versions CP and RT.
Changes common to CTA versions RT, PF, and ST.
Possible change of {type definition}
to {declared type definition}. Separate both because it's
a separate question and to allow me to turn change coloring off
for it while working on the rest of CTA.
Changes related to definition xs:error that aren't part of CP
proper.Editorial changes made while working on CTA.
They should be presented together with CTA but should be separate
because if CTA should go down, these should be broght back.
More editorial changes made while working on CTA.
An editorial change from "given [some set]"
to "subject to [a particular set of blocking keywords]",
as suggeested by the WG in Pisa.
Change to make every type table
have a default type. If none is specified in the XML source
declaration, it's the declared type.
Change to enforce run-time CTA restriction
check from the parent element (in ELV(CT)), not from the
child (in ELV(E)).Wrappers for conditional type assignment.
Make this 'post' if cta is 'post' or 'colour'. Otherwise
make this 'pre'.Sandy's revision to CTA.MSM's revision to CTA.Sandy's revision #2 to CTA.Material backed out of Sandy's revision #2 to CTA.MSM's revision of CTA through r3.Parts of CTA withdrawn.
Material added by CTA and promptly deleted by 4419, as add.
Material added by CTA and promptly deleted by 4419, as del.
Make "type alternative" a component.MSM's revisions to cta-ta. Subject to change.Editorial notes.
Material added by CTA and promptly deleted by revision ta.
Amendments to various proposals from 2006/10 F2F.
Further amendments found in the minutes of the ftf but not
found here. Made by MSM 2006-12-21; marked with separate
diff group to simplify sanity checks.
Replace all occurrence of ur-type with anyType/anySimpleType.
Multiple substitution group heads.
Namespace fix-up for applying default attributes.
Second cut, independent of b2105, for namespace fix-up
for defaulted attributes.
Third cut on namespace fix-up
for defaulted attributes, independent of b2105 and b2105b.
Things common to b2105b and b2105c. Should be
the same as whichever of them you are showing.
Auxiliary diff group, to simplify display of b2105b.
Namespace fix-up for default values of type QName
(no, do not perform namespace fixup).
Namespace fix-up for default values of type QName
(yes, do perform namespace fixup).
Make complex type restriction work with IDC on local elements.
An auxiliary diff group, to make the addition of a conditional
clause display correctly.
Amendments to Assertion proposal from telecon Dec. 15, 2006:
remove <report>
Amendments to Assertion proposal from telecon Dec. 15, 2006:
new PSVI property to indicate which Assertion is violated.
Indicate which identity constraint is violated.
Amendments to Assertion proposal from telecon Dec. 15, 2006:
Disallow <assert> in extension.
Make it clear that overridden facets do not appear in derived simple types.
Clarify what "valid restriction" means for facet values in the context of
simple type restriction.
Minor editorial changes that should be brought to the WG
as a group, originally marked ep99. What's here so far is:
- Trivial editorial tweak to a reference to namespaces.
- Resolution to bug 4336 (correct a nested 'must').
- Add requirements for XML Schema 1.1 to the informative references.
- Add a note warning that IDs with value constraints go beyond DTDs.
Some editorial changes in ELV(CT).
Tag 'resolved' more systematically, with links to the two QName
resolution rules.
Minor editorial changes that should be brought to the WG
as a group. '99' is an arbitrary number than means "later".
When these go to the WG, give them a 'real' EP number (as was
done with ep19).
Minor editorial changes that may be taken care of or not.
Minor editorial changes and corrections in the 1.0 text.
Namespace fixup for chameleon include and IDC.
By changing unprefixed QNames to use the new target namespace.
By changing the default namespace according to the setting of the
xpathDefaultNamespace attribute.
Clarify how chameleon include changes namespace names in wildards.
By saying "as if the included/redefined schema doc had targetNamespace".
Includes WG amendment to proposal as shipped.
Editorial changes that go with 2067-2 proposal.
Provide identifiers of different versions of the schema language.
Explicit amendments received at 2007-01/02 face 2 face meeting.
"Editors, do your best" amendments received at 2007-01/02 face 2 face meeting.
Auxiliary diff group (to allow text motion to show white instead of yellow and red)
MSM's revision of f2f0701b.
Sandy's revision of f2f0701c.
MSM's revision of f2f0701d (and possibly other stuff, if I'm not
careful).
Rejected options for type defaulting with multi-sub-group-heads.
Movement of text originally added
by consent-1020 and moved by f2f0701c
Specification of how XPath 2.0 expressions are evaluated
for assertions: make an XDM instance with the element as its
root, decorated with the context-determined type (or the
instance-specified type).
Part of tree-trimming proposal Sandy wishes to revert.
Other changes Sandy wishes to include in tree-trimming proposal.
Additional changes for Version A, about what type to use when CDT is absent.
Additional changes for Version B, about what type to use when GTD is absent.
Use context-determined type definition in the XDM tree.
Use governing type definition in the XDM tree.
Alternate description of XDM typing: everything is
labeled untyped or untypedAtomic, and if you want types
you had better cast for them.
Included as a precaution for the day when QT sees that
we're proposing to build data model instances with
type annotations that have not been validated.
Changes common to trimtree-cdt,
trimtree-gtd, and typelesstree. Things should be set up
so that everything works right if
(a) all three of those, plus ttcommon, plus tmcc, are
colour (for the proposal to go to WG), or
(b) exactly ONE of those three is colour or post,
and ttmc is pre, and ttcommon is colour or post
(for final text).
tt 'master of ceremonies': text for
labels like 'Version A:'
Proposal M for typing the trimmed tree. The sub-tree is typed as usual;
the root is anyType (also try to type the simple content of the root)
Try to type simple content.
Amendments to the proposal from WG.
Amendments to the proposal from editors.
Further amendments (MSM, 24 July 2007).
Editorial note(s) for 4416.
Wrapper for 4416 changes that need a wrapper.
Set this to post if any 4416 changes are colour or nsq or post,
otherwise to pre.
Text for 4416 that's no longer used.
Use string instead of token as the datatype for assertion tests
Schema location fails to resolve.
Validation rule for xsi: attributes.
xsi:type fails to resolve and lax assessment.
MSM addition(s) to b4299
WG amendment to 4299 proposal.
xsi:type must resolve
Assessment vs. strict-assessment for elements.
Allowing abstract elements in substitution groups.
Support default attribute group to ease xml: attribute handling.
Amendments to 4314 proposal approved by WG during Mar. 2007 F2F.
Allow type promotion in assertions.
XPath evaluation errors.
Take "assertion"s under "restriction" and "extension" into account.
Allow multiple ID attributes on the same element
Clarify that ID elements idenfity themselves, as opposed to their parents.
To clarify that schema built-in components can be referenced from within a
schema document without needing an "import" element.
Intro words. Should become "pre" when we decide which one to pick.
Solution A: references to all built-in components.
Solution B: references to all built-in components in schema namespace.
Changes common to A and B.
Solution C: references to all components in schema namespace.
Solution C': references to all components in schema/instance namespace.
Remove the requirement that "it's an error for an xsi: schema location to
appear after the first occurrence of the corresponding namespace".
Remove the misleading note below the complex type extension note.
WG amendments to proposal for 4438.
Add the back the "all derivation can be done by an extension followed by a
restriction" rule.
Store annotations under "openContent" and "defaultOpenContent".
Augment base infoset with information from legacy types.
Augment base infoset with information from element-only content.
More infoset properties for default attributes.
More infoset properties for default attributes - wg amendment.
Update to prose about filing comments.
Proposed name change: XSD. (With all that that entails.)
Second layer of changes. No particular reason for this to be separate
from b4399 except possible regret in cases of overlapping changes.
Apply IDREF/ENTITY/ENTITIES rules to defaulted values.
A type derived from a union type can't be a member of that union type.
Forbid "complexType" and "complexContent" having different "maixed" values.
Use "effective value constraint" for applying default attributes.
Allow value constraints on ID-derived types.
Don't apply value constraints specified on xsi: attributes.
Amendments from 2007-06-08 telecon on 4363.
Specify XPath static and dynamic contexts.
(The XPath property record has been split off; it is now xppr so
that it can be included by CTA.)
Different ways to specify mapping rules for IDC fields.
Don't repeat selector rules.
Repeat selector rules.
Factor selector rules out symmetrically.
Editorial notes for 4419.
MSM revisions for 4419 (at same time as b4416-4).
Text for 4419 we got cold feet over but didn't want to delete yet.
For complex types with simple content, the CDT is inherited
from its base type.
Definition of the XPath property record. For use by b4419 and by cta.
Support <xs:override>.
MSM's tentative revisions to 4767, in case SG hates them.
Editorial notes for support of <xs:override>.
Update QName references in chameleon included documents.
MSM tweaks to wording of 2067n.
Specify that in chameleon include / redefine, it's the
munged document that should conform.
Another attempt to specify that in chameleon include / redefine, it's the
munged document that should conform.
Layer 1 of proposal for forward processing using minVersion and
maxVersion attributes.
SG's revision.
MSM's revision.
Clarification of conformance issues related to proposal b2825.
Amendments made by the WG on 2007-08-03 telecon to proposals:
2825, CTA, and 2067.
Notes and other changes made by the editors on very general / vague
WG instructions on 2007-08-03 telecon. This is a separate diff
group so we can make in nsq in the Last Call publication candidate.
Changes to appendix describing changes since 1.0, in draft of August 2007.
Text movement in the appendix describing changes since 1.0, in draft of
August 2007. The deletions and additions aren't really deletions or
additions, just movement. (Or in some cases, wrappers.)
Show this as colour only for special purposes,
if you're sure you know what you're doing.
A bunch of diff groups to cover paragraphs in the changelist appendix
added by some named group and now deleted / moved.:
Updates made for LCWD of August 2007.
Change to definition of eligible item set to resolve issue 2316
(use of the term 'constructed').
Changes prepared for the 'consent agenda' for the meeting of 2008-01-18,
covering the following issues.
MSM's reworking of 3892Also covers bug 4470 and 5258Typos and small problems reported by Michael Kay.Also covers bug 5263Typos and small problems reported by Xan Gregg.Infelicity reported by Xan Gregg.Also covers bug 5077Alignment with Datatypes in description of
{member type definitions} property.
Changes prepared for the 'consent agenda' for the meeting of 2008-02-15,
covering the following issues.
Bug 5168, to make maxVersion exclusive.Bug 5200, to support "##definedSibling".MSM's proposed modes to b5200.Sandy's revision.5200-related material to suppress.5200b-related material to suppress.Editorial notes for bug 5200.Added by vm19, deleted by 5200b, appears as 'add'.Added by vm19, deleted by 5200b, appears as 'del'.Bug 5273, to move "xpathDefaultNamespace" to
field/selector.Bug 5276, relax rules around targetNamespace on local
elements/attributes.Alternative wording 3: restriction, not anyType.Bug 5281, to check names in those constraints.Bug 5282, to overlapping sub-groups in UPA; definition
of sub-groups.Bug 5157, to clarify notQName example.Bug 5286, to remove component constraints from 3.x.3.Editorial notes for bug 5286.Extensions for bug 5286, approved 11 April 2008.SG text that MSM is unsure of (deleted after WG
coin toss went to version d).MSM alternatives to b5286c text.Text about attribute reference circularity,
unrolled by WG from 5286b, to be integrated with fixed-point
proposal.MSM mods to 5286e.Changes drafted for 5286e but then not taken.Some auxiliary changes / moves to do silently.Material added by vm19
and deleted by b5286b, tagged as an 'add'.Material added by vm19
and deleted by b5286b, tagged as a 'del'.Editorial notes for bug 5286b.Editorial notes for bug 5286e.Bug 5165, first installment. Split constraint sections
so that each constraint is in a subsection. Supply headings; perhaps supply
introductory paragraphs? (No. Do them. but separate them
from the mechanical split-and-add-section-title.
Bug 5165, splits on infoset contributions (to allow these to
be rolled back if we hate them).
Bug 5165, first sketch of introductory paragraphs.
Bug 5165, first installment, splits that contain
only deleted material (so the new head should not show up).
We could just include the material with other stuff nearby, but that
clutters things up. This way things like the old Particle Valid (Restriction)
constraint are enclosed a bit more tidily and are easier to skip over in
navigation.
Bug 5165, draft text I'm not using but don't want to
delete yet.Material added by b4299b and deleted by
b5165a.
Material added by b4299b and deleted by
b5165a.
Simplify mentions of QNames and QName matching;
no issue number, this is just an editorial proposal. It came up
when I was looking at bug 5257.
Ancillary diff group for ep20Ancillary diff group for ep20Define components as having expanded names.Collapse local vs. global rule in
"Element Sequence Accepted (Particle)"EP 20 ideas that didn't take.Define L(T) for basic terms T.More variable names in constraintnotes.invisible changes for ep22, do not colour.Changes for 5164, use 'assessment' and 'validation'
more consistently.Changes for 5164, silent.Changes drafted for 5164, then dropped.Introduce dot operator for components and info items.Containing elements for ep24.Introduce variables for infoset contributions.Further changes (related to clarity and choice of
verb) in constraintnotes. Began as part of ep22, but it will be
more difficult and controversial and should be factored out.invisible changes for ep98, do not colour.XPath subset used by Assertions and Type Alternatives.Changes not related to 5426.WG changes to XPath subsetJohn Arwe, miscellaneous editorial stuffSandy's amendments to 5145.John Arwe, miscellaneous editorial stuffJohn Arwe, miscellaneous editorial stuffChoose between the following alternatives.First formulation of how "prohibited" is handled.Sandy's formulation.Another formulation (option C) from MSM.Yet another formulation (option C2) from MSM.Late amendments from John Arwe (24 March).John Arwe, miscellaneous editorial stuffSandy's amendments to 5158.John Arwe, miscellaneous editorial stuffMichael Kay, miscellaneous editorial stuffMichael Kay, editorial comment on 3.4.4material added by rq17a2, deleted by 5195, as addmaterial added by rq17a2, deleted by 5195, as delVersion A: 3 definitions.Version B: 1 definitionSML request for XPath subset namesMake reference to 'absent' as value clearereditorial fixes, MKeditorial fixes, MKchange not adopted by WGamendments from WGeditorial fixes, JAmore editorial fixes, JAadded by ww, deleted by 5144added by ww, deleted by 5144must and errorchanges for 3220 that may need separate handlingchanges related to xsi: attributes and conformance;
hope to deal with it under a different bug.revisions to 3220, 30 April 2008.
Not sure whether these really need to be separate or not.xml-1.0 vs xml-1.1 datatypes, terminologybug 5504 don't allow extensions to have different annotations
on shared components (not complete)John Arwe, miscellaneous editorial stuff; changes missed
first time roundAssertions on simple typesImplementation-defined primitivesChange many occurrences of normalized value to initial value,
and make whitespace processing explicit in cvc-simple-type (String
Valid) rule. Separate because this may be controversial and if so it
needs to be easily unwound.Tentative change for unknown facets.Sandy's revision.Bug 5152, break the large unbroken reprdef blocks
where possible.Bug 5152, textual changes, with SG's revisions
incorporated.Tentative change for unknown facets.Parts of 5152 relevant for simple types (and thus for 3251).Hack for element xr.ct11Material added by b2195,
moved by 5152. Old location, as add.Material added by b2195,
moved by 5152. New location, as add.Material added by 2850 and then moved.
Old position, as add.Material added by 2850 and then moved.
New position, as add.Material added by
b2861cc-1, moved by 5152. Old location, as add.Material added by
b2861cc-1, moved by 5152. New location, as add.Material deleted by b2861cc-3
and (later!) moved by 5152.
Old location, as del.Material deleted by b2861cc-3 and
(later!) moved by 5152. New location, as del.Material added by b3836-2 and then moved.
Old location, as add.
When b5152 is post, this should be pre (to prevent the material showing up
in the wrong place). (The new location will be labeled b3836-2, so as to
show up in color in diff-1.0, in its new location, and not colored in other
forms. Ditto for the following.)
Material added by b3836-2 and then moved.
New location, as add.
If disp(b5152) = pre, then pre,
else if disp(b5152) = post/colour then disp(b3836-2)
When b5152-movement is post, this should be post. When 3836-2 is (also)
colour, this should be colour. This is for the new location, when it
cannot be labeled b3836-2.
Material added by b5194,
moved by 5152. Old location, as add.Material added by b5194,
moved by 5152. New location, as add.Material added by b5286d,
moved by 5152. Old location, as add.Material added by b5286d,
moved by 5152. New location, as add.Material added by vm13 and then moved.
Old location, as add.Material added by vm13 and then moved.
New location, as add.Allow run-time checking of subsumption.Disallow non-trivial "all" restricts "sequence/choice".
Declined by WG after discussion, 2008-05-23, removed from source.
Suggest to delete.Definition of schema-document conformance.Valid schemaProposal to deprecate Definition of 'actual value'.list equality / identitymissing componentsmissing componentsmissing componentsmissing componentscommon text for abWG instructions from 30 May 2008last-ditch proposal: magic nss are impl-dependentWG instructions from 6 June 2008Task force for assertions on simple typesPentimentiPortmanteauWG instructions from 13 June 2008Bug 5904, Unknown attributes in vc namespaceBug 5905, vc:typeAvailable and vc:typeUnavailableBug 5930, defaultOpenContent in the S4SDBug 5934, Typo concerning mixed="true" on simpleContentChanges made immediately after publication of 2008-06-21
(in sotd only), to re-orient toward WG use.Bug 4316, Make sure namespace prefixes are used
appropriately throughout structuresBug 4690, use "locally declared type" instead of
"context-determined type"Bug 5140, small editorial changes in 3.3Bug 5148, consistent usage of "if present, otherwise..."Bug 5476, resolve xsi:schemaLocation if directedBug 5639, facets in simple type restrictionBug 5916, remove left-over ed-note.Bug 5917, fix a typo.Bug 5800, complete the list of required infoset properties.Bug 6120, remove blockDefault from SD4SD.Bug 6144, store annotation under idc+ref on element decls.Bug 6156, fix typo in 3.4.2.Bug 6162, disallow sibling in attribute wildcards.Bug 6165, make "any" and "anyAttribute" consistent.Bug 6165, secondary text movement (see comments).Bug 6166, disallow notNamespace="".Bug 6167, add "one or more is true" to "Attribute Wildcard Intersection".Bug 6170, default attributes comes the last.Bug 6163, make all wildcard unions expressible.Related to bug 6163, use "union", not "intersection".material deleted by 6163 that was added after 1.0Bug 6175, UPA appendix reference to Wildcard Intersection.Bug 5003, access to xml:lang from CTA.Bug 5003, editorial notes.Bug 5003, CTA with opening up ancestors.Bug b5003a, revert some b5426w changes.Bug 5003, changes common to options A and B.Bug 5003, CTA without opening up ancestors.Bug 5003, make inheritable attributes available in the PSVI.Bug 5907, fix CTA XPath subset to allow cast and constructors.Bug 5907, revert some b5426w changes.Bug 5907, editorial notes about BNF changes.Bug 5940, {type table} EDC and skip wildcards and {open content}.Bug 5918, consider <redefine in global component mapping.Bug 5918, introduce "top-level" and "global".Bug 6159, handle "defined" and "sibing" in "Item Valid (Wildcard)".Bug 6161, wildcard subset "must" to "are"; "'s" to ".".Bug 6161, editorial note describing the change.Bug 6201, particle constraints applicability.Bug 6204, base type of anyType.Bug 6540, make collections empty for assertins.Bug 6541, required functions for assertions.Bug 6561, context-determined type table and anyType/skip wildcards.Bug 6561, context-determined type table and skip wildcards.Bug 6561, context-determined type table and anyType.Bug 6561, post-adoption changes and cleanup.Bug 6685, particle restriction external references.Bug 6685, deletion of appendix. Separate for technical reasons.Bug 6685, changes not adopted as part of 6685.Bug 6011, use [base URI] for relative schema locations.Bug 6011, clarification (reverses some of a change made for 5800).Bug 6187, Remove "eltref" from sectoin headings.Bug 6227, change anySimpleType back to anyType in
Type Derivation OK (simple).Bug 6233, fix the link to the "nil" clause.Bug 6235, health warning about producing bad component from mapping rules.Late fix to wording for 5800.Bug 6021, define scoped transformation to make override more useful.Bug 6021, text movement.Variant of 6021 which includes redefine in the definition of the
target set of an override element.Variant of 6021 which excludes redefine in the definition of the
target set of an override element.Material added by 4767b and deleted by 6021, as addMaterial added by 4767b and deleted by 6021, as delBug 1913, update "derived".Bug 5412, update "lax assessment" to cover "missing components".Bug 5748, update 3.4.4.4 section title.Bug 6008, small editorial changes.Bug 6008 followup, small editorial changes.Bug 6008 followup, changes proposed but reverted
(retained temporarily, delete after December 2009).Bug 6012, consistent text.Bug 6012, some post-adoption cleanup (John is a careful reader).Bug 6014, normative text issues.Editorial proposal EP 28, some terminology in
composition section (experimental)Editorial proposal EP 29, fixpoint semantics of includeMichael Kay's proposedl revisions to EP 29Editorial proposal EP 30, exclude schema description components
from unionsMSM affiliation change.Feature at risk note about "all" group restriction.Feature at risk note about reporting schema errors at runtime.Priority feedback on changes to "block" in complex types.Namespace fixup bug.Namespace foxup for inherited attributes.drop some dead text about xpath subsetcomponent diagram(s)Michael Kay's comments on 6021, silently adopted by
editors in preparation for next Last Call.Bug 6021, things still to be done. Someday.Unilateral last-minute editors' changes for
last-call draft of January 2009.Discuss overlap between assertions and identity constraint and ctaClarify, again and louder, that unimported nss cannot be referred toText movement for b5779WAI PF on user control of dereferencing policynode sequence, not node setJohn Arwe, list of confusing bitslate revisions (to propose as amendments in call)changes to W3C referencesmisc references cleanupmisc references cleanup - quiet text movementLate revision for bug 2632make note in example about assertions more helpfulnew example for type table and wildcardsnew example for wildcardswhitespace in list types are fixed to collapseAdd SCD and update mentions of xpointerChanges made for CR publication April 2009Recast definition of 'laxly assessed',
common text.Bug 6722 text movement FROM locs (show silently sometimes).Bug 6722 text movement TO locs (show silently sometimes).Paternalsm and open content, 2009-07-24.Annotation mapping, text from Bugzilla.Some small clarifications on compositions, courtesy of John Arwe.Allow refs to "all" groups from within "all" groupss/constitute a restriction of ... with respect to .../
is the result of overlaying ... with .../Provide both dated and undated schema documentsMK request to number the bits of Change list"inherited attributes" are not used by Assertions.Remove default value for "nillable" from schema for schemas.Recast description of symbol spaces.Bug 6015, further on 'validation' and 'infoset' (resolved
together with 5164)
K Braun on dynamic EDCfollowup (he never tires)K Braun on restricted unionsK Braun on wildcard unionsK Braun on open contentFurther editorial nits in Complex Type mapping rules section
(John Arwe)Section name changes (JA again)Use 'XML Representation of X, Y, and Z Schema Components'Use 'The xs:... Element'Conformance clause revisionsFix botched proposal for bug 6043 explicitTimezonefix problem in definition of governing element declarationSilent parts of 7913Bug 8282, changing variable names for schema docsBug 8342, small wording change for HTChanges for Last Call draft of Dec 2009material we don't want to delete but which shouldn't showWhitespace facetenumeration facetFundamental facetConstraining facet
Introduction
This document sets out the structural part of the XML Schema Definition Language.
Chapter 2 presents a for XSD, including an introduction to the
nature of XSD schemas and an introduction to the XSD
abstract data model, along with other terminology used throughout
this document.
Chapter 3, , specifies the precise
semantics of each component of the abstract model, the
representation of each component in XML, with reference to a DTD
and anXSD schema for
an XSD document type, along with a detailed mapping
between the elements and attribute vocabulary of this
representation and the components and properties of the abstract
model.
Chapter 4 presents , including the
connection between documents and schemas, the import, inclusion
and redefinition of declarations and definitions and the
foundations of schema-validity assessment.
Chapter 5 discusses , including the
overall approach to schema-validity assessment of documents, and
responsibilities of schema-aware processors.
The normative appendices include a for the XML representation of
schemas and
.
The non-normative appendices include the and a .
This document is primarily intended as a language definition
reference. As such, although it contains a few examples, it is
not primarily designed to serve as a motivating
introduction to the design and its features, or as a tutorial for
new users. Rather it presents a careful and fully explicit
definition of that design, suitable for guiding implementations.
For those in search of a step-by-step introduction to the design,
the non-normative
is a much better starting point than this document.
Introduction to Version 1.1
The Working Group has three main goals for this version of W3C
XML Schema:
Significant improvements in simplicity of design and
clarity of exposition without loss of backward
or forward compatibility;
Provision of support for versioning of XML languages
defined using this
specification, including the XML vocabulary
specified here for use in schema documents.
Provision of support for
co-occurrence constraints, that is constraints which make the
presence of an attribute or element, or the values allowable
for it, depend on the value or presence of other attributes or
elements.
These goals are
in tension with one another. The Working Group's strategic guidelines
for changes between versions 1.0 and 1.1 can be summarized as follows:
Support
for versioning (acknowledging that this may be
slightly disruptive to the XML transfer syntax at the
margins)
Support for co-occurrence
constraints (which will certainly involve additions to the XML
transfer syntax, which will not be understood by 1.0
processors)
Bug fixes (unless in specific
cases we decide that the fix is too disruptive for a point
release)
Editorial changes
Design cleanup will possibly change behavior in edge
cases
Non-disruptive changes to type hierarchy
(to better support current and forthcoming international
standards and W3C recommendations)
Design cleanup will possibly change component structure
(changes to functionality restricted to edge cases)
No
significant changes in existing functionality
No changes
to XML transfer syntax except those required by version control
hooks, co-occurrence
constraints and bug fixes
The aim with regard
to compatibility is that
All schema documents conformant to version 1.0 of this
specification should also conform to version 1.1, and should
have the same behavior across 1.0 and 1.1 implementations
(except possibly in edge cases and in the details of the
resulting PSVI);
The vast majority of schema documents conformant to
version 1.1 of this specification should also conform to
version 1.0, leaving aside any incompatibilities arising from
support for versioning or
co-occurrence constraints, and when they are
conformant to version 1.0 (or are made conformant by the
removal of versioning information), should have the same
behavior
across 1.0 and 1.1 implementations (again except possibly in
edge cases and in the details of the resulting PSVI);
Purpose
The purpose of XML Schema Definition Language: Structures is to define the nature of
XSD schemas and their component parts,
provide an inventory of XML markup constructs with which to
represent schemas, and define the application of schemas to XML
documents.
The purpose of an XSD schema is to define and describe a
class of XML documents by using schema components to constrain
and document the meaning, usage and relationships of their
constituent parts: datatypes, elements and their content and
attributes and their values. Schemas can also provide for
the specification of additional document information, such as
normalization and defaulting of attribute and element values.
Schemas have facilities for self-documentation. Thus, XML Schema Definition Language: Structures can
be used to define, describe and catalogue XML vocabularies for
classes of XML documents.
Any application that consumes well-formed XML can use the
formalism defined here to express
syntactic, structural and value constraints applicable to its
document instances. The XSD formalism allows a useful level of
constraint checking to be described and implemented for a wide
spectrum of XML applications. However, the language defined by
this specification does not attempt to provide all
the facilities that might be needed by applications. Some applications
will require constraint capabilities not expressible in this
language, and so will need to perform their own additional
validations.
Namespaces and Language Identifiers
XSD Namespaces
The Schema Namespace (xs)
The XML representation of schema components uses a vocabulary
identified by the namespace name http://www.w3.org/2001/XMLSchema.
For brevity, the text and examples in this specification use
the prefix xs: to stand for this
namespace; in practice, any prefix can be used.
The namespace for schema documents is unchanged from version
1.0 of this specification, because any schema document valid
under the rules of version 1.0 has essentially the same
semantics under this specification as it did under
version 1.0 (Second Edition).
There are a few exceptions to this rule, involving errors in
version 1.0 of this specification which were not reparable by
errata and which have therefore been fixed only in this
version of this specification, not in version 1.0.
The data model used by and other
specifications, namely , makes use of
type labels in the
XSD namespace (untyped,
untypedAtomic) which are not defined in this
specification; see the
specification for details of those types.
Users of the namespaces defined here should be aware, as a
matter of namespace policy, that more names
in this namespace may be given
definitions in future versions of this or other
specifications.
The Schema Instance Namespace (xsi)
This specification defines
several attributes for direct use in any XML documents, as
described in .
These attributes are in the namespace whose name ishttp://www.w3.org/2001/XMLSchema-instance.
For brevity, the text and examples in this specification use
the prefix xsi: to stand for this namespace; in
practice, any prefix can be used.
Users of the namespaces defined here should be aware, as a
matter of namespace policy, that more names
in this namespace may be given
definitions in future versions of this or other
specifications.
The Schema Versioning Namespace (vc)
The pre-processing of schema documents described in
uses
attributes in the namespace
http://www.w3.org/2007/XMLSchema-versioning.
For brevity, the text and examples in this specification use
the prefix vc: to stand for this
namespace; in practice, any prefix can be used.
Users of the namespaces defined here should be aware, as a
matter of namespace policy, that more names in this namespace
may be given definitions in future versions of this or other
specifications.
Namespaces with Special Status
Except as otherwise specified elsewhere in this specification,
if components are in a schema, or source
declarations are included in an XSD schema document, for
components in any of the following namespaces, then the
components, or the declarations, should agree with the
descriptions given in the relevant specifications and with the
declarations given in any applicable XSD schema documents
maintained by the World Wide Web Consortium for these
namespaces. If they do not, the effect is implementation-dependent
and not defined by this specification.
http://www.w3.org/XML/1998/namespace
http://www.w3.org/2001/XMLSchema
http://www.w3.org/2001/XMLSchema-instance
http://www.w3.org/2007/XMLSchema-versioning
Depending on implementation details, some processors may
be able to process and use (for example) variant forms of the
schema for schema documents devised for specialized purposes;
if so, this specification does not forbid the use of such variant
components. Other processors, however, may find it
impossible to validate and use alternative components for
these namespaces; this specification does not require them
to do so. Users who have an interest in such specialized
processing should be aware of the attending interoperability
problems and should exercise caution.
This flexibility does not extend to the components described in
this specification or in as being
included in every schema, such as those for the primitive and
other built-in datatypes. Since those components are by
definition part of evey schema, it is not possible to have
different components with the same expanded names present in
the schema without violating constraints defined elsewhere
against multiple components with the same expanded names.
Components and source declarations must not specify
http://www.w3.org/2000/xmlns/ as their
target namespace. If they do, then the schema
and/or schema document is in error.
Any confusion in the use, structure, or meaning of this namespace
would have catastrophic effects on the interpretability of
this specification.
Conventional Namespace Bindings
Several namespace prefixes are conventionally used in this
document for notational convenience. The following bindings are
assumed.
fn bound to
http://www.w3.org/2005/xpath-functions (defined
in
html bound to
http://www.w3.org/1999/xhtml
my (in examples) bound to the target namespace
of the example schema document
rddl bound to
http://www.rddl.org/
vc bound to
http://www.w3.org/2007/XMLSchema-versioning (defined
in this and related specifications)
xhtml bound to
http://www.w3.org/1999/xhtml
xlink bound to
http://www.w3.org/1999/xlink
xml bound to
http://www.w3.org/XML/1998/namespace (defined in
and )
xs bound to http://www.w3.org/2001/XMLSchema
(defined in this and related specifications)
xsi bound to
http://www.w3.org/2001/XMLSchema-instance (defined in this and
related specifications)
xsl bound to
http://www.w3.org/1999/XSL/Transform
In practice, any prefix bound to the appropriate namespace
name may be used (unless otherwise specified by the definition
of the namespace in question, as for xml and
xmlns).
Schema Language Identifiers
Sometimes other specifications or Application Programming
Interfaces (APIs) need to refer to the XML Schema Definition Language in
general, sometimes they need to refer to a specific version of
the language. To make such references easy and enable consistent identifiers to be used, we provide the following
URIs to identify these
concepts.
Identifies the XML Schema Definition Language in general, without referring
to a specific version of it.
Identifies the language described in version X.Y of the XSD specification. URIs of this form refer to
a numbered version
of the language in general. They do not distinguish among different working drafts or
editions of that version. For example,
http://www.w3.org/XML/XMLSchema/v1.0 identifies
XSD version 1.0 and http://www.w3.org/XML/XMLSchema/v1.1 identifies
XSD version 1.1.
Identifies the language described in the N-th edition of version X.Y of
the XSD specification. For example, http://www.w3.org/XML/XMLSchema/v1.0/2e
identifies the second edition of XSD version 1.0.
Identifies the language described in the N-th edition of version
X.Y of
the XSD specification published on the particular date
yyyy-mm-dd. For example,
http://www.w3.org/XML/XMLSchema/v1.0/1e/20001024
identifies the language
defined in theXSD version 1.0 Candidate
Recommendation (CR) published on 24 October 2000, and
http://www.w3.org/XML/XMLSchema/v1.0/2e/20040318
identifies the language
defined in theXSD version 1.0 Second Edition Proposed
Edited Recommendation (PER)
published on 18 March 2004.
Please see for a
complete list of XML Schema Definition Language identifiers which exist to date.
Dependencies on Other Specifications
The definition of XML Schema Definition Language: Structures depends on the following
specifications:
,
, ,
and
.
See for a tabulation of the
information items and properties specified in which this
specification requires as a precondition to schema-aware
processing.
defines some
datatypes which depend on definitions in
and ; those definitions, and therefore
the datatypes based on them, vary between version 1.0 (, ) and
version 1.1 (,
) of those specifications. In any
given schema-validity-
episode, the choice of the 1.0 or the 1.1 definition of those
datatypes is implementation-defined.
Conforming implementations of this specification may provide
either the 1.1-based datatypes or the 1.0-based datatypes, or
both. If both are supported, the choice of which datatypes to
use in a particular assessment episode should be under user
control.
It is a consequence of the
rule just given that implementationsmay provide the heuristic of using the 1.1
datatypes if the input is labeled as XML 1.1, and the 1.0
datatypes if the input is labeled 1.0. It should be noted
however that the XML version number is not required to be
present in the input to an assessment episode, and in any case
the heuristic should be subject to override by users, to
support cases where users wish to accept XML 1.1 input but
validate it using the 1.0 datatypes, or accept XML 1.0 input and
validate it using the 1.1 datatypes.
Some users will perhaps wish to accept only XML 1.1 input, or
only XML 1.0 input. The rules
just given ensure that conforming implementations of this
specification which accept XML input may accept XML 1.0, XML
1.1, or both and may provide user control over which versions
of XML to accept.
Documentation Conventions and Terminology
The section introduces the highlighting and typography as used
in this document to present technical material.
Unless otherwise noted, the entire text of
this specification is normative. Exceptions include:
notes
sections explicitly marked non-normative
examples and their commentary
informal descriptions of the consequences of rules
formally and normatively stated elsewhere (such informal
descriptions are typically introduced by phrases like
Informally, ... or It is a
consequence of ... that ...)
Explicit statements that some material is normative are not
to be taken as implying that material not so described
is non-normative
(other than that mentioned in the list just given).
Special terms are defined at their point of introduction in the
text. For example a term is something used with a
special meaning. The definition is labeled as such
and the term it defines is displayed in boldface. The end of the
definition is not specially marked in the displayed or printed
text. Uses of defined terms are links to their definitions, set
off with middle dots, for instance term.
Non-normative examples are set off in boxes and accompanied by
a brief explanation:
The definition of each kind of schema component consists of a
list of its properties and their contents, followed by
descriptions of the semantics of the properties:
An example property
References to properties of schema components are links to the
relevant definition as exemplified above, set off with curly
braces, for instance
.
For a given component C, an expression
of the form C.
denotes the (value of the) property
for component C.
The leading C. (or more) is sometimes omitted,
if the identity of the component and any other omitted properties
is understood from the context.
This dot operator is left-associative, so
C..
means the same as
(C.) .
and denotes the value of property
within the component or which itself
is the value of C's property.
White space on either side of the dot operator has no significance
and is used (rarely) solely for legibility.
For components C1 and C2, an expression
of the form C1 . = C2 .
means that C1 and C2 have the same value for the
property (or properties) in question. Similarly,
C1 = C2 means that C1 and C2 are
identical, and C1.
= C2 that C2 is the value of
C1..
The correspondence between an element information item which is
part of the XML representation of a schema and one or more schema
components is presented in a tableau which illustrates the
element information item(s) involved. This is followed by a
tabulation of the correspondence between properties of the
component and properties of the information item. Where context
determines which of several
different components corresponds to the
source declaration, several tabulations, one per
context, are given. The property correspondences are normative,
as are the illustrations of the XML representation element
information items.
In the XML representation, bold-face attribute names (e.g.
count below) indicate a required attribute
information item, and the rest are optional. Where an attribute
information item has an enumerated type definition, the values
are shown separated by vertical bars, as for size
below; if there is a default value, it is shown following a
colon. Where an attribute information item has a built-in simple
type definition defined in , a hyperlink
to
its definition therein is given.
The allowed content of the information item is shown as a
grammar fragment, using the Kleene operators ?,
* and +. Each element name therein is
a hyperlink to its own illustration.
The illustrations are derived automatically from the . In the case of apparent
conflict, the takes
precedence, as it, together with the Schema Representation Constraints,
provide the normative statement of the form of XML
representations.
Description of what
the property corresponds to, e.g. the value of the
sizeattribute
References to elements in the text are links to the relevant
illustration as exemplified above, set off with angle brackets,
for instance .
Unless otherwise specified, references to attribute values
are references to the actual value of the attribute information
item in question, not to its normalized value or to other forms
or varieties of value associated with it.
For a given element information item E, expressions of the
form E has att1 = V
are short-hand for there is an attribute information
item named att1 among the attributes of E and
its actual value
is V.
If the identity of E is clear from context, expressions
of the form att1 = V
are sometimes used.
The form att1 ≠ V is also used
to specify that the actual value of att1 is
notV.
References to properties of information items as defined in
are notated as links to the relevant
section thereof, set off with square brackets, for example
children.
Properties which this specification defines for information
items are introduced as follows:
The value the property
gets.
References to properties of information items defined in this
specification are notated as links to their introduction as
exemplified above, set off with square brackets, for example
.
The dot operator described above
for components and their properties is also used for information items
and their properties. For a given information item I, an expression
of the form I .
denotes the (value of the) property
for item I.
Lists of normative constraints are typically introduced with
phrase like
all of the following are true (or ... apply),
one of the following is true,
at least one of the following is true,
one or more of the following is true,
the appropriate case among the following is true,
etc.
The phrase one of the following is true
is used in cases where the authors believe the items listed
to be mutually exclusive (so that the distinction between
exactly one and one or more
does not arise). If the items in such a list are not in fact
mutually exclusive, the phrase one of the following
should be interpreted as meaning one or more of the
following.
The phrase the appropriate case among the following
is used only when the cases are thought by the authors to be
mutually exclusive; if the cases in such a list are not in fact
mutually exclusive, the first applicable case should be
taken. Once a case has been encountered with a true condition,
subsequent cases must not be tested.
The following highlighting is used for non-normative commentary
in this document:
General comments directed to all readers.
Within normative prose in this
specification, the words may,
should,must and must not are
defined as follows:
Schemas,
schema documents, and processors are
permitted to but need not behave as described.
It is recommended that schemas,
schema documents,
and
processors behave as described, but there
can be valid reasons for them not to; it is important that the
full implications be understood and carefully weighed before
adopting behavior at variance with the recommendation.
(Of schemas and
schema documents:)
Schemas and documents are required to behave as
described; otherwise they are in error.
(Of
processors:)
Processors are
required to behave as described.
Schemas,
schema documents, and processors
are forbidden to behave as
described; schemas and documents which nevertheless
do so are in error.
A failure of a schema
or schema
document to conform to the rules of this
specification.
Except as otherwise specified,
processors must distinguish error-free (conforming) schemas
and schema documents used in from those with errors;
if a schema used in
or a schema document used in constructing a schema
is in error,
processors must report the fact;
if more than one is in error, it is implementation-dependent
whether more than one is reported as being in error.
If one or more of the constraint codes given
in is applicable, it is
implementation-dependent how many of them, and which,
are reported.
Failure of an XML document to be valid against a particular
schema is not (except for the special case of a schema
document consulted in the course of building a schema) in
itself a failure to conform to this specification and thus,
for purposes of this specification, not an error.
Notwithstanding the fact that (as just noted) failure to be
schema-valid is not a violation of this specification and
thus not strictly speaking an error as defined here,
the names of the PSVI properties (for attributes) and (for elements) are retained for
compatibility with other versions of this specification, and
because in many applications of XSD, non-conforming
documents arein error for
purposes of those applications.
A feature or construct defined in this specification
described as deprecated is retained in this
specification for compatibility with previous versions
of the specification, and but its use is not advisable and
schema authors should avoid its use if possible.
Deprecation has no effect on the conformance of schemas
or schema documents which use deprecated features.
Since deprecated features are part of the specification,
processors must support them, although some processors
may
choose to issue warning messages when deprecated
features are encountered.
Features deprecated in this version of this specification
may be removed entirely in future versions, if any.
These definitions describe in terms
specific to this document the meanings assigned to these terms by
. The specific wording follows
that of .
Where these terms appear without special highlighting,
they are used in their ordinary senses and do not express conformance
requirements. Where these terms appear highlighted within
non-normative material (e.g. notes), they are recapitulating
rules normatively stated elsewhere.
This
specification provides a
further description
of error and of conformant
processors' responsibilities with respect to errors in.
Conceptual Framework
This chapter gives an overview of XML Schema Definition Language: Structures at the level of its
abstract data model. provides details
on this model, including a normative representation in XML for the
components of the model. Readers interested primarily in learning
to write schema documents will find it most
useful first to read for a
tutorial introduction, and only then to consult the sub-sections of
named
XML Representation of ...
for the details.
Overview of XSD
An XSD schemais
a set of components such as type definitions and
element declarations. These can be used to assess the validity of
well-formed element and attribute information items (as defined
in ), and furthermore
to
specify additional information about
those items and their descendants. These augmentations
to the information set make explicit information that
was implicitly
present in the original
document (or in the original document
and the governing schema, taken together), such as normalized and/or default values for attributes
and elements and the types of element and attribute information
items. The input information set
is
also augmented with information about the validity of the
item, or about other properties described in this
specification.We refer to the augmented infoset which
results from conformant processing as defined in this
specification as the post-schema-validation
infoset, or PSVI. Conforming processors may provide
access to some or
all of the PSVI, as described in . The mechanisms by which
processors provide such
access to the PSVI are neither defined nor constrained by this
specification.
As it is used in this specification, the
term schema-validity assessment has three aspects:
Determining local schema-validity, that is
whether an element or attribute information item satisfies
the constraints embodied in the
relevant components of an
XSD schema(specifically the
element or attribute declaration and/or
type definition);
Determining an
overall validation outcome for the item
by combining local schema-validity with
the results of schema-validity assessments of its
descendants, if any; and
Determining the appropriate
augmentations to the infoset (and, if desired, exposing them
to downstream applications in some way, to record this
outcome).
Throughout this specification, the word assessment
is used to refer to the overall process of local validation,
recursive determination of
validation outcome, and infoset augmentation, i.e. as a short form for
.
Validation is the process of determining
whether an XML document, an element information item, or an
attribute information item obeys the constraints expressed in a
schema; in the context of XSD, this amounts to calculating the
value of the appropriate item's property.
As just defined, validation produces not a binary result, but a
ternary one: if the information item is ,
it will be either valid or invalid, but if no applicable
declaration is found, its validity will be unknown (and its
property will have the
value notKnown). Whether in a particular application
notKnown should be treated in the same way as
invalid or differently is outside the scope of this
specification; sometimes one choice is appropriate,
sometimes the other.
In phrases such as
and length valid restriction, the word
valid is used in its ordinary English sense
of conforming to some set of rules, not
necessarily limited to rules expressed in an XSD schema.
In general, a valid document
is a document whose contents obey the constraints expressed in a
particular schema. Since a document may be validated against many
different schemas, it is often clearer to speak of a document
being valid against a particular schema. When this
specification is used, document validity can be defined
operationally in terms of the post-schema-validation infoset properties on the nodes of
the document (in particular ). Several similar but distinct kinds of validity are
usefully distinguished, for which terms are defined below in
.
Because the property is part of the post-schema-validation infoset, it should be
evident that any full of an item by definition
entails the validation of that item. Conversely, since the
property is recursive and
depends upon many other pieces of information which are part of
the post-schema-validation infoset, validation also typically entails at least partial
. The processes denoted by the two terms thus
overlap and are not always distinguishable; often the same
process can be referred to by either term. In this specification,
the term is used when it is desired
to stress the calculation of the complete post-schema-validation infoset, including
properties whose values have no effect on validity.
The term validation, in contrast, is used
when it is desired to focus primarily on the validity
of the item, treating the other information generated in
the process as merely incidental.
When there is no particular
emphasis one way or the other, the choice of terms is
necessarily arbitrary, or grounded in the history of
this and related specifications. Historical reasons,
rather than connotation, determine the
use of the term validation instead of
in terms like
post-schema-validation infoset,
, and
Validation Rules.
During , some or
all of the element and attribute information items in the input
document are associated with declarations and/or type
definitions; these declarations and type definitions are then
used in the of those items, in a
recursive process. The declaration associated with an information
item, if any, and with respect to which its validity is assessed in a given assessment episode
is said to govern the item, or to be its
governing element or attribute declaration.
Similarly the type definition with respect to which the
type-validity of an item is assessed is its
governing type definition.
See also the definitions of and
(for elements) and and (for
attributes).
XSD Abstract Data Model
This specification builds on and
. The concepts and definitions used
herein regarding XML are framed at the abstract level of
information
items as defined in . By
definition, this use of the infoset provides a
priori guarantees of well-formedness
(as defined in ) and namespace
conformance (as defined in )
for all candidates for and for all
schema documents.
Just as and
can be described in terms of
information items, XSD schemas can be described in terms of
an abstract data model. In defining schemas in terms of
an abstract data model, this specification rigorously specifies
the information which must be available to a conforming
XSD processor. The abstract model for schemas is
conceptual only, and does not mandate any particular
implementation or representation of this information. To
facilitate interoperation and sharing of schema information, a
normative XML interchange format for schemas is provided.
Schema
component is the generic term for the building blocks
that make up the abstract data model
of the schema. An XSD schema is a set of schema components. There are
several kinds of schema component, falling
into three groups. The primary schema components, which may (type
definitions) or must (element and attribute declarations) have
names, are as follows:
Simple type definitions
Complex type definitions
Attribute declarations
Element declarations
The secondary schema components, are as
follows:
Attribute group definitions
Identity-constraint definitions
Type alternatives
Assertions
Model group definitions
Notation declarations
Finally, the helperschema components provide small
parts of other schema components; they are dependent on their context:
Annotations
Model groups
Particles
Wildcards
Attribute Uses
The
name covers all the different kinds of
schema component defined in this specification.
During validation, declaration
components are associated by (qualified) name to information items
being validated.
On the other hand, definition components define internal
schema components that can be used in other schema
components.
Declarations
and definitions mayand in
some cases must have and be identified by
names, which are
NCNames as defined by .
Several
kinds of component have a target namespace, which
is either absent or a
namespace name, also as defined by . The target namespace serves to identify
the namespace within which the association between the component
and its name exists.
An expanded name, as defined in
, is a pair consisting
of a namespace name, which may be absent, and a local
name. The expanded name of any component with both a
property and a
property is the pair
consisting of the values of those two properties.
The expanded name of a declaration is used to help
determine which information items will be
governed by
the declaration.
At the abstract level, there is no requirement that the
components of a schema share a target namespace. Any schema for
use in of documents
containing names from more than one namespace will of necessity
include components with different target namespaces. This contrasts
with the situation at the level of the XML representation of
components, in which each schema document contributes
definitions and declarations to a single target namespace.
Validation, defined in detail
in , is a relation between information
items and schema components. For example, an attribute
information item is validated
with respect to an attribute declaration, a list of element
information items with respect to a
content model, and so on. The following sections briefly
introduce the kinds of components in the schema abstract data
model, other major features of the abstract model, and how they
contribute to validation.
Type Definition Components
The abstract model provides two kinds of type definition
component: simple and complex.
This specification
uses the phrase type definition in cases where no
distinction need be made between simple and complex
types.
Type definitions form a hierarchy with a single root. The
subsections below first describe characteristics of that
hierarchy, then provide an introduction to simple and complex
type definitions themselves.
Type Definition Hierarchy
Except for xs:anyType, every type definition is, by construction,
either a restriction or an
extension of some
other type definition. The exception
xs:anyType is a of itself.
With the exception of the loop on xs:anyType, the
graph of these relationships forms
a tree known as the Type Definition
Hierarchy with xs:anyType as its
root.
The type definition used as the basis
for an extension or
restriction is
known as the base type definition of that
definition.
If a type definition D can reach a type definition B by following
its base type definition chain, then D is said to be
derived from B.In most cases, a type definition is
derived from other type definitions. The only exception is
xs:anyType, which is derived from itself.
A
type defined with the same constraints as its , or with more, is
said to be a restriction. The added constraints might include narrowed
ranges or reduced alternatives. Given two types A and B, if the definition of
A is a restriction of the
definition of B, then members of type A are always locally
valid against type B as well.
A complex
type definition which allows element or attribute content in
addition to that allowed by another specified type definition
is said to be an extension.
Conceptually, the definitions of
and
overlap: given a
type T, a vacuous
of T and a vacuous
of T will each
accept the same inputs as valid. The syntax specified
in this version of this specification, however, requires
that each type be defined either as a restriction
or as an extension, not both. Thus even though the
vacuous extension of T accepts the same inputs as
the vacuous restriction, it will not be accepted in
contexts which require restrictions of T.
A special complex type
definition, (referred to in earlier versions of this
specification as 'the ur-type definition') whose
name is anyType in the XSD namespace, is
present in each XSD schema. The definition of
anyType serves as default
type definition for element declarations whose XML
representation does not specify one.
A special simple type
definition, whose name is error in the XSD
namespace, is also present in each XSD schema. The
XSD error type
has no valid instances. It can be used in any place where
other types are normally used; in particular, it can be used
in conditional type assignment to cause elements which satisfy
certain conditions to be invalid.
For brevity, the text and examples in this specification often
use the qualified names xs:anyType and
xs:error for these type definitions. (In
practice, any appropriately declared prefix can be used, as
described in .)
Simple Type Definition
A simple type definition is a set of constraints on strings
and information about the values they encode, applicable to the
normalized value of an attribute information item or of an element
information item with no element children. Informally, it
applies to the values of attributes and the text-only content
of elements.
Each simple type definition, whether built-in (that is,
defined in ) or user-defined, is a restriction of itsbase type definition.
A
special restriction of
xs:anyType, whose name is
anySimpleType in the
XSD namespace, is the root of the for all simple type
definitions. xs:anySimpleType has a lexical space containing
all sequences of characters in the Universal Character
Set (UCS) and a value space containing all
atomic values
and all finite-length lists of
atomic values.
As with xs:anyType, this
specification sometimes uses the qualified name
xs:anySimpleType to designate this type
definition.The
built-in list datatypes all have xs:anySimpleType as their
base type
definition.
There is a further special datatype
called anyAtomicType, a
restriction of
xs:anySimpleType, which is the base type definition
of all the primitive
datatypes.This type definition is often referred
to simply as xs:anyAtomicType.
It too is
considered to have an unconstrained lexical space. Its value
space consists of the union of the value spaces of all the
primitive datatypes.
Datatypes can be constructed from other datatypes by
restricting the value space or lexical space of a
using zero or more
s, by specifying the new datatype as a list
of items of some ,
or by defining it as a union of some specified sequence of
.
The mapping from lexical space to value space is unspecified
for items whose type definition is xs:anySimpleTypeor xs:anyAtomicType. Accordingly
this specification does not constrain processors'
behavior in areas
where this mapping is implicated, for example checking such
items against enumerations, constructing default attributes or
elements whose declared type definition is xs:anySimpleTypeor xs:anyAtomicType,
checking identity constraints involving such items.
The Working Group expects to return to this area in a future
version of this specification.
provides mechanisms for defining new simple type definitions
by restrictingsome primitive
or ordinary datatype. It also
provides mechanisms for constructing new simple type
definitions whose members are lists of items
themselves constrained by some other simple type definition, or
whose membership is the union of the memberships of some other
simple type definitions. Such list and union simple type
definitions are also restrictions of
xs:anySimpleType.
For detailed information on simple type definitions, see
and . The
latter also defines an extensive inventory of pre-defined
simple types.
Complex Type Definition
A complex type definition is a set of attribute declarations
and a content type, applicable to the attributes and
children of an element information item respectively. The
content type may require the children to contain
neither element nor character information items (that is, to be
empty), or to be a
string which belongs to a particular simple type, or to contain a sequence of
element information items which conforms to a particular model
group, with or without character information items as well.
Each complex type definition other than xs:anyType is
either
a restriction of a complex base type
definition
or
an extension of
a simple or complex base type
definition.
A complex type which extends another does so by having
additional content model particles at the end of the other
definition's content model, or by having additional attribute
declarations, or both.
For the most part, this
specification allows only appending, and not other kinds of
extensions. This decision simplifies application processing
required to cast instances from
the derived type to the base type.
One special case allows the
extension of all-groups in ways that do not
guarantee that the new material occurs only at the end of
the content.Another
special case is extension via s in interleave
mode.
For detailed information on complex type definitions, see .
Declaration Components
There are three kinds of declaration component: element, attribute,
and notation. Each is described in a section below. Also
included is a discussion of element substitution groups, which
is a feature provided in conjunction with element
declarations.
Element Declaration
An element declaration is an association of a name with a
type definition, either simple or complex, an (optional)
default value and a (possibly empty) set of identity-constraint
definitions. The association is either global or scoped to a
containing complex type definition. A top-level element
declaration with name 'A' is broadly comparable to a pair of
DTD declarations as follows, where the associated type
definition fills in the ellipses:
<!ELEMENT A . . .>
<!ATTLIST A . . .>
Element declarations contribute to validation as part of model group
validation, when their defaults
and type components are checked against an element information
item with a matching name and namespace, and by triggering
identity-constraint definition validation.
For detailed information on element declarations, see .
For an overview of identity constraints, see
.
Element Substitution Group
When XML vocabularies are defined using
the
DTD syntax defined by ,
a reference in a content model to a particular name is satisfied
only by an element in the XML document whose
name and content correspond exactly to those given in the
corresponding element type
declaration.
The element type declaration
of
is not quite the same as the as defined
in this specification: does not
distinguish between element declarations and
type definitions as
distinct kinds of object in the way that this specification
does. The element type declaration of
specifies both the kinds of properties
associated in this specification with element declarations
and the kinds of properties associated here with
(complex) type definitions.
Through the
mechanism of element substitution
groups, XSD provides a more powerful model
than DTDs do
supporting substitution of one named element for
another. Any top-level element declaration can serve
as the defining member, or head, for an element .
Other top-level element declarations, regardless of target
namespace, can be designated as members of the
headed by this element. In a suitably enabled content model, a
reference to the head validates
not just the head itself, but elements corresponding to any
other member of the as well.
All such members must have type definitions which are
either the same as the head's type definition or derived
from it. Therefore, although the names of elements
can vary widely as new namespaces and members of the
are defined, the content of member elements is
constrained by the type
definition of the
head.
Note that element substitution groups are not represented as
separate components. They are specified in the property values
for element declarations (see
).
Attribute Declaration
An attribute declaration is an association between a name and
a simple type definition, together with occurrence information
and (optionally) a default value. The association is either
global, or local to its containing complex type definition.
Attribute declarations contribute to validation as part of complex type
definition validation, when
their occurrence, defaults and type components are checked
against an attribute information item with a matching name and
namespace.
For detailed information on attribute declarations, see
.
Notation Declaration
A notation declaration is an association between a name and
an identifier for a notation. For an attribute or element information item to
be valid with respect to a
NOTATION simple type definition, its value must
have been declared with a notation declaration.
For detailed information on notation declarations, see .
Model Group Components
The model group, particle, and wildcard components
contribute to the portion of a complex type definition that
controls an element information item's content.
Model Group
A model group is a constraint in the form of a grammar
fragment that applies to lists of element information items. It
consists of a list of particles, i.e. element declarations,
wildcards and model groups. There are three varieties of model
group:
Sequence (the element information items match the
particles in sequential order);
Conjunction (the element information items match the
particles, in any order);
Disjunction (the element information items match
one or more
of the particles).
Each model group denotes a set of
sequences of element information items. Regarding that set of
sequences as a language, the set of sequences recognized by a
group G may be written L(G). A model group Gis said to accept
or recognize the members of L(G).
For detailed information on model groups, see .
Particle
A particle is a term in the grammar for element content,
consisting of either an element declaration, a wildcard or a
model group, together with occurrence constraints.
Particles contribute to validation as part of complex type
definition validation, when
they allow anywhere from zero to many element information items
or sequences thereof, depending on their contents and
occurrence constraints.
The name is used to refer to any of the three kinds of
components which can appear in particles. All
Terms are themselves Annotated Components. A
basic term is an or a
.A basic
particle is a whose is a .
A
particle can be used in a complex type definition to
constrain the validation of
the children of an element information item; such a
particle is called a content model.
XSDcontent models are similar
to but more expressive than
content models; unlike
, XSDdoes not restrict the form of content models describing
mixed content.
Each content model, indeed each
particle and each term,
denotes a set of sequences of element information items. Regarding
that set of sequences as a language, the set of sequences recognized
by a particle P may be written L(P).
A particle P is said to
accept or recognize the members of
L(P). Similarly, a term Taccepts or recognizes the members
of L(T).
The language accepted by a content model plays a role in determining
whether an element information item is locally valid or not: if the
appropriate content model does not accept the sequence of elements
among its children, then the element information item is not locally
valid. (Some additional constraints must
also be met: not every
sequence in L(P) is locally valid against P. See
.)
No assumption is made, in the definition above,
that the items in the sequence are themselves valid; only the
expanded names of the items in the sequence are relevant in
determining whether the sequence is accepted by a particle.
Their validity does affect whether their parent is (recursively)
valid as well as locally valid.
If a sequence S is a member of L(P),
then it is necessarily possible to trace a path through the
basic particles
within P, with each item within S corresponding to a matching particle
within P. The sequence of particles within P corresponding to S
is called the of S in P.
This has nothing to do with
XPath expressions.
When there may otherwise be danger of confusion, the
described here may be referred to as the match path of S
in P.
For detailed information on particles, see .
Attribute Use
An attribute use plays a role similar to that of a
particle, but for attribute declarations: an attribute
declaration
used by a complex type definition is embedded within
an attribute use, which specifies whether the declaration
requires or merely allows its attribute, and whether it has a
default or fixed value.
Wildcard
A wildcard is a special kind of particle which matches element
and attribute information items dependent on their namespace
namesand optionally on their local names.
For detailed information on wildcards, see .
Constraint Components
This section describes constructs which
use expressions to constrain the
input document; using them, certain rules can be expressed
conveniently which would be inconvenient or impossible to
express otherwise. Identity-constraint definitions are associated with
element declarations; assertions are associated with type
definitions; conditional type assignment using type alternatives
allows the type of an element instance to be chosen based on
properties of the element instance (in particular, based on the
values of its attributes).
Identity-constraint Definition
An identity-constraint definition is an association between a name
and one of several varieties of identity-constraint related to
uniqueness and reference. All the varieties use expressions to pick out sets of information
items relative to particular target element information items
which are unique, or a key, or a valid reference, within a specified
scope. An element information item is only valid with respect to an element
declaration with identity-constraint definitions if those definitions
are all satisfied for all the descendants of that element
information item which they pick out.
For detailed information on identity-constraint definitions, see
.
In version 1.0 of this specification, identity constraints used;they now use .
Type Alternative
A component
(type alternative for short)
associates a type definition with a predicate.
Type alternatives are used in conditional
type assignment, in which the choice of
for elements governed by a particular element declaration
depends on properties of the document instance. An element
declaration may have a which contains a
sequence of type alternatives; the predicates on the alternatives
are tested, and when a predicate is satisfied, the type
definition paired with it is chosen as the element instance's
.
The provisions for conditional type assignment are inspired by,
but not identical to, those of .
For detailed information on Type Alternatives, see
.
Assertion
An assertion is a predicate associated with a type, which is
checked for each instance of the type. If an element or attribute information item
fails to satisfy an assertion associated with a given type,
then that information item is not locally valid
with respect to that type.
For detailed information on Assertions, see .
Overlapping Functionality of Constraint Components
Many rules that can be enforced by identity constraints
and conditional type assignment can also be formulated
in terms of assertions. That is, the various constructs have
overlapping functionality.
The three forms of constraint differ from each other in various
ways which may affect the schema author's choice of formulation.
Most obviously, the post-schema-validation infoset will differ somewhat, depending
on which form of constraint is chosen.
Less obviously, identity constraints are associated with
element declarations, while assertions are associated with
type definitions. If it is desired to enforce a particular
property of uniqueness or referential integrity associated
with a particular element declaration E, of type T,
the schema author may often choose either an identity constraint
associated with E, or an assertion associated with T.
One obvious difference is that
elements substitutable for E
are required to have types derived from T, but
are not required to enforce the identity constraints (or
the nillability) of E. If the constraint applicable to E
should be enforced by elements substitutable for E, it
is often most convenient to formulate the constraint as
an assertion on T; conversely, if only some elements of
type T are intended to be subject to the constraint, or if
elements substitutable for E need not enforce the constraint, then it
will be more convenient to formulate the rule as an
identity constraint on E.
Similar considerations sometimes apply to the choice between
assertions and conditional type assignment.
Because identity constraints and conditional type assignment are
simpler and less variable than assertions, it may be easier
for software to exploit or optimize them. Assertions have
greater expressive power, which means they are often
convenient. The rule of least power applies here;
it is often preferable to use a less expressive notation in
preference to a more expressive one, when either will suffice.
See .
Group Definition Components
There are two kinds of convenience definitions provided to
enable the re-use of pieces of complex type definitions: model
group definitions and attribute group definitions.
Model Group Definition
A model group definition is an association between a name and
a model group, enabling re-use of the same model group in
several complex type definitions.
For detailed information on model group definitions, see
.
Attribute Group Definition
An attribute group definition is an association between a
name and a set of attribute declarations, enabling re-use of
the same set in several complex type definitions.
For detailed information on attribute group definitions, see
.
Annotation Components
An annotation is information for human and/or mechanical
consumers. The interpretation of such information is not defined
in this specification.
For detailed information on annotations, see .
Constraints and Validation Rules
The specification describes two kinds
of constraints on XML documents: well-formedness and
validity constraints. Informally, the
well-formedness constraints are those imposed by the definition
of XML itself (such as the rules for the use of the < and >
characters and the rules for proper nesting of elements), while
validity constraints are the further constraints on document
structure provided by a particular DTD.
The preceding section focused on validation, that is the constraints on
information items which schema components supply. In fact
however this specification provides four different kinds of
normative statements about schema components, their
representations in XML and their contribution to the validation of information items:
Constraints on the schema components themselves,
i.e. conditions components must satisfy to be components at
all. They are located
in the sixth sub-section of the per-component
sections of and tabulated in
.
Constraints on the representation of schema
components in XML beyond those which are expressed in
.
They are located
in the
third sub-section of the per-component sections of and tabulated in .
Contributions to validation associated with schema
components. They are located
in the fourth sub-section of the
per-component sections of and
tabulated in .
Augmentations to post-schema-validation infosets expressed by schema
components, which follow as a consequence of
.
They are located
in the fifth
sub-section of the per-component sections of and tabulated in .
The last of these, schema information set contributions, are
not as new as they might at first seem. XML validation augments the XML information set in similar
ways, for example by providing values for attributes not present
in instances, and by implicitly exploiting type information for
normalization or access. (As an example of the latter case,
consider the effect of NMTOKENS on attribute white
space, and the semantics of ID and
IDREF.) By including schema information set
contributions, this specification makes explicit some features
that XML leaves implicit.
Conformance
Within the context of this
specification, conformance can be claimed for schema
documents, for schemas,
and for
processors.
A schema document
conforms to this specification if and only if
It is valid with respect to the
top-level element declaration for in
the schema specified
in .
That is,
when assessed using
element-driven validation
and stipulating the declaration for , then
in its post-schema-validation infoset, the element
has a
property with value full or partial and a
property
with value valid.
No element in the schema document violates any of the
Schema Representation Constraints set out in
.
While conformance of schema documents is a precondition for
the mapping from schema documents to schema components described
in this specification, conformance of the schema documents does
not guarantee that the result of that mapping will be a schema
that conforms to this specification. Some constraints (e.g. the
rule that there must be at most one top-level element
declaration with a particular expanded name) can only be
checked in the context of the schema as a whole.
Because component correctness
depends in part upon the other components present, the
XML mapping rules defined in this specification do not always
map conforming schema documents into components that satisfy
all constraints. In some cases, the mapping will produce
components which violate constraints imposed at the component
level; in others, no component at all will be produced.
In this version of this specification, Schema Representation
Constraints concern only properties of the schema document which
can be checked in isolation. In version 1.0 of this
specification, some Schema Representation Constraints could not
be checked against the schema document in isolation, and so it
was not always possible to say, for a given schema document,
whether it satisfied the constraints or not.
A schema conforms to this specification
if and only if it consists of components which individually and
collectively satisfy all the relevant constraints specified in
this document, including but not limited to all the Schema Component Constraints.
This specification defines no API or other interface
for interacting with schemas, so a conformance claim for
a schema is not normally testable in any standardized way.
However, if an interface is provided which enables a user
to interrogate various properties of the schema and check
their values, conformance can usefully be claimed for the
schema.
This specification distinguishes several
classes of conforming processors, which are defined in terms
of the following concepts.
A
validator (or instance validator) is a
processor which validates an XML instance document against a
conforming schema and distinguishes between valid documents
and others, for one or more of the definitions of validity
(root-validity,
deep validity,
or
uniform validity)
defined below in section
.
Conforming validators may additionally support other
definitions of validity defined in terms of the post-schema-validation infoset.
A schema-validity
assessor (or just assessor)
is a processor which performs full or partial
of an XML instance document,
element information item, or attribute information item,
with
reference to a conforming schema, and provides access to the
entirety of the resulting post-schema-validation infoset.
The means by which an provides
access to the post-schema-validation infoset is implementation-defined.
A general-purpose processor
is a or which accepts schemas represented in the
form of XML documents as described in .
The Schema Representation
Constraints are to be enforced after, not
before, the conditional-inclusion pre-processing
described in .
A
schema processor which is not a
processor is a special-purpose
processor.
By separating the conformance requirements relating to the
concrete syntax of schema documents, this specification
admits processors which use schemas stored in optimized binary
representations, dynamically created schemas represented as
programming language data structures, or implementations in
which particular schemas are compiled into executable code such
as C or Java. Such processors can be said
to conform to this
specification as
but not as
processors.
Web-aware processors are
network-enabled processors which are not only
but
which additionally must be capable of accessing schema
documents from the World Wide Web as described in and .
.
In version 1.0 of this specification the class of processors
was termed
conformant
to the XML Representation of Schemas. Similarly, the
class of processors was
called fully conforming.
Several important classes of processor
can be defined in terms of the concepts just given:
Validators
which accept arbitrary schemas expressed
in the form of sets of schema documents (i.e.,
are ); some
general-purpose validators may additionally be
.
Assessors
which accept arbitrary schemas expressed
in the form of sets of schema documents (i.e.,
are ); some
general-purpose assessors may additionally be
.
Validators
which do not accept arbitrary schemas expressed
in the form of sets of schema documents
Typically a special-purpose validator will either have a
built-in (hard-coded) schema, or else will accept arbitrary
schemas in some form other than schema documents.
Processors (other than those otherwise defined) which
perform some task, service, or activity which depends at
least in part on the contents of some schema, and which
do so in ways which are consistent with the provisions of
this specification.
The class of other
special-purpose tools is not,
as defined here, a particularly informative description
of a piece of software. It is expected that other
specifications may wish to define processes depending
in part upon schemas, and to require that implementations
of those processes conform to this specification;
this conformance class provides a reference point for
such requirements, and for such claims of conformance.
Although this specification provides just these standard levels of
conformance, it is anticipated that other conventions can be
established in the future. There is no
need to modify or republish this specification to define such
additional levels of conformance.
See and
for terminology and concepts which may be helpful in
defining the behavior of conforming processors and/or
claiming conformance to this specification.
Schema-validity and documents
As noted above, in general a document is valid against
a particular schema if it obeys the constraints imposed
by that schema. Depending on the nature of the application
and on the specific invariants to be enforced, different
forms of validity may be appropriately required by an
application, a specification, or other users of XSD.
This section defines terminology for use in describing the
requirements of applications or other technologies which use
XSD schema to describe constraints on XML documents.
Conformance to this specification cannot be claimed for XML
documents other than schema documents; this specification
imposes no requirements on documents, validity-related or
otherwise, and the terms defined in this section play
no role in conformance
to this specification. They are defined here for the
convenience of users of this specification who do wish to
impose specific requirements on documents.
The terms defined capture some commonly used requirements, but
the specification of which documents should be regarded as
acceptable for a specific application, or as conforming to a
given specification, is out of scope for this specification.
Applications and specifications which use XSD are free to
specify whatever constraints they see fit on documents; the
provision of terms for the concepts identified here should not
be taken to imply that other rules for document acceptability
are discouraged or inappropriate.
All the terms defined below require that the document's root
element be assessed using either element-driven validation (when the
intended root element of the schema is clearly specified ) or else
strict wildcard
validation (if several different root elements are
acceptable).
A document is root-valid against a given
XSD schema if and only if after the document's root
element has =
valid and
= full or partial.
A document is deep-valid against a given
XSD schema if and only if after
The document's root element has = valid.
The document's root element has
= full or
partial.
No element in the document has = invalid.
No attribute in the document has = invalid.
The second and third clauses are necessary to ensure that
invalid descendants of laxly validated elements are caught;
they do not cause their laxly validated ancestor to have
= invalid.
A document is uniformly valid against a given
XSD schema if and only if after
The document's root element has = valid.
The document's root element has
= full.
See for the definition
of the property.)
It follows from the first and second clauses that every
element and attribute in the document has been
validated and each of them is valid. (This distinguishes
uniform validity from deep validity;
a deep-valid document may include elements and attributes
whose validity is notKnown, perhaps because they
are laxly assessed and no declarations were found for
them, or because they were .)
The absence of error codes does not suffice to make a document
valid according to any of the definitions just given; the
property will be empty (or
absent) for any root element with = notKnown.
Validators which expose only the property and fail to distinguish in
their behavior between = notKnown and = valid can thus easily
mislead unwary users. A frequent cause of
= notKnown is
the failure of the element information item to any
declaration in the schema.
Names and Symbol Spaces
As discussed in , most
schema components (may) have names. If all such names were
assigned from the same pool, then it would be
impossible to have, for example, a simple type definition and an
element declaration both with the name title in a
given target namespace.
Therefore this specification introduces the term symbol
space to denote a collection of names, each of which is
unique with respect to the others.
Within a given schema there are distinct symbol spaces
for each kind of named definition and declaration component identified
in , except that
simple type definitions and complex type definitions share a
symbol space. Within a given symbol space, names
must be unique;
as a consequence, each expanded name within a given
symbol space uniquely identifies a single component.
The same expanded namemay however appear in more than one symbol space without
conflict. For example, assuming that the namespace prefix
my is bound to some particular namespace,
both a simple type definition and a top-level element declaration
can bear the name my:abc without conflict or
necessary relation between the two. But it is not possible
for both a simple type definition and a complex type
definition, or two distinct top-level element declarations,
to share the name my:abc.
Locally scoped attribute and element declarations are special
with regard to symbol spaces. Their names are not included
in the global symbol spaces for attribute and element names;
each complex type definition defines its own attribute symbol
space, and elements local to a complex type definition are
constrained by ,
but not by means of symbol spaces. Their names
are not regarded as being in any particular symbol space.
So, for example, two
complex type definitions having the same target namespace can
contain a local attribute declaration for the unqualified name
priority, or contain a local element declaration
for the name address, without conflict or
necessary relation between the two.
Schema-Related Markup in Documents Being Validated
XML Schema Definition Language: Structures defines
several attributes for direct use in any XML documents. These
attributes are in the schema instance namespace
(http://www.w3.org/2001/XMLSchema-instance) described in above. All schema processors
must
have appropriate attribute declarations for these attributes
built in, see ,
, and
.
As described above (), the
attributes described in this section are referred to in this
specification as xsi:type,
xsi:nil, etc. This is shorthand for
an attribute information item whose namespace
name is
http://www.w3.org/2001/XMLSchema-instance and whose local
name is type (or
nil, etc.).
xsi:type
The or used in validation of an element is usually
determined by reference to the appropriate schema components. An
element information item in an instance may, however,
explicitly assert its type using the attribute
xsi:type. The value of this attribute is a QName; see for the means by which the QName is associated with a type
definition.
xsi:nil
XML Schema Definition Language: Structures introduces a mechanism for signaling that an element
must be accepted as valid
when it has no content despite a content type which does not
require or even necessarily allow empty content. An element
can bevalid
without content if it has the attribute xsi:nil
with the value true. An element so labeled must
be empty, but can carry attributes if permitted by the
corresponding complex type.
xsi:schemaLocation, xsi:noNamespaceSchemaLocation
The xsi:schemaLocation and
xsi:noNamespaceSchemaLocation attributes can be
used in a document to provide hints as to the physical location
of schema documents which can be used for . See for details on the use of these
attributes.
The xsi:schemaLocation attribute typically appears
in XML document instances being validated; it is distinct from
the schemaLocation attribute defined for some
elements in schema documents (which is not always a hint
but sometimes a firm directive).
Representation of Schemas on the World Wide Web
On the World Wide Web, schemas are conventionally represented
as XML documents (preferably of MIME type
application/xml or text/xml, but see
of ),
conforming to the specifications in . For
more information on the representation and use of schema
documents on the World Wide Web
see and
.
Schema Component Details
Introduction
The following sections provide full details on the composition
of all schema components, together with their XML representations
and their contributions to . Each section is devoted to a
single component, with separate subsections for
properties: their values and significance
XML representation and the mapping to properties
constraints on representation
validation rules
post-schema-validation infoset contributions
constraints on the components themselves
The sub-sections immediately below introduce conventions
and terminology used throughout the component sections.
Components and Properties
Components are defined in terms of their properties, and each
property in turn is defined by giving its range, that is the
values it may have. This can be understood as defining a
schema as a labeled directed graph, where the root is a schema,
every other vertex is a schema component or a literal (string,
boolean, decimal) and every labeled edge is a property.
The graph is not acyclic: multiple copies of
components with the same name in the same symbol spacemust not exist, so in some cases re-entrant
chains of properties will exist.
A schema and its components as defined in this chapter are an
idealization of the information a schema-aware processor
requires: implementations are not constrained in how they
provide it. In particular, no implications about literal
embedding versus indirection follow from the use below of
language such as properties . . . having . . .
components as values.
Component properties are simply named
values. Most properties have either other components or
literals (that is, strings or booleans or enumerated keywords)
for values, but in a few cases, where more complex values are
involved, a property
value may itself be a collection of named values, which we call
a property record.
Throughout this
specification, the term absent is used as a
distinguished property value denoting absence. Again this should not be
interpreted as
constraining implementations, as for instance between using a
null value for such properties or not representing
them at all.
A property value
which is not absent is present.
Any property not defined as optional is always
present; optional properties which are not present are
taken to have absent as their
value. Any property identified as a having a set, subset or
list value might have an empty value unless this is explicitly
ruled out: this is not the same as absent. Any property value identified
as a superset or subset of some set
might be equal to that set,
unless a proper superset or subset is explicitly called for. By
'string' in Part 1 of this specification is meant a sequence of
ISO 10646 characters identified as legal XML
characters in .
It is implementation-defined whether a schema processor uses the
definition of legal character from or
.
XML Representations of Components
The principal purpose of XML Schema Definition Language: Structures is to define a set of schema
components that constrain the contents of instances and augment
the information sets thereof. Although no external
representation of schemas is required for this purpose, such
representations will obviously be widely used. To provide for
this in an appropriate and interoperable way, this specification
provides a normative XML representation for schemas which makes
provision for every kind of schema component. A document in this
form (i.e. a element information item)
is a schema document. For the schema
document as a whole, and its constituents, the sections below
define correspondences between element information items (with
declarations in
and ) and schema components. The key element information items in
the XML representation of a schema are in the XSD namespace, that
is their namespace
nameishttp://www.w3.org/2001/XMLSchema. Although a common way of creating
the XML Infosets which are or contain schema documents will be
using an XML parser, this is not required: any mechanism which
constructs conformant infosets as defined in is a possible starting
point.
Two aspects of the XML representations of components presented
in the following sections are constant across them all:
All of them allow attributes qualified with namespace names
other than the XSD namespace itself: these appear as
annotations in the corresponding schema component;
All of them allow an as their
first child, for human-readable documentation and/or
machine-targeted information.
A recurrent pattern in the XML
representation of schemas may also be mentioned here. In many
cases, the same element name (e.g. element or
attribute or attributeGroup), serves
both to define a particular schema component and to incorporate
it by reference. In the first case the name
attribute is required, in the second the ref
attribute is required. These
two usages are mutually exclusive, and sometimes also depend on
context.
The descriptions of the XML representation
of components, and the Schema Representation
Constraints, apply to schema documents after,
not before, the conditional-inclusion pre-processing described
in .
The Mapping between XML Representations and
Components
For each kind of schema component there is a corresponding
normative XML representation. The sections below describe the
correspondences between the properties of each kind of schema
component on the one hand and the properties of information
items in that XML representation on the other, together with
constraints on that representation above and beyond those
expressed in the
.
The language used is as if the correspondences were mappings
from XML representation to schema component, but the mapping in
the other direction, and therefore the correspondence in the
abstract, can always be constructed therefrom.
In discussing the mapping from XML representations to schema
components below, the value of a component property is often
determined by the value of an attribute information item, one of
the attributes of an element information item. Since schema
documents are constrained by the
, there is always a simple type
definition associated with any such attribute information item.
With reference to any
string, interpreted as denoting
an instance of a given datatype, the term
actual value denotes the value to which the
lexical mapping of that datatype maps the string.
In the case of attributes in
schema documents, the string used as the
lexical representation is normally the normalized value of the
attribute. The associated datatype is, unless otherwise specified,
the one identified in the declaration of the attribute, in the
schema for schema documents; in some cases (e.g. the
facet, or fixed and default values
for elements and attributes) the associated datatype will
be a more specific one,
as specified in the appropriate
XML mapping rules. The actual value
will often be a string, but can also be an integer, a
boolean, a URI reference, etc. This term is also occasionally
used with respect to element or attribute information items in a
document being assessed.
Many properties are identified below as having other schema
components or sets of components as values. For the purposes of
exposition, the definitions in this section assume that (unless
the property is explicitly identified as optional) all such
values are in fact present. When schema components are
constructed from XML representations involving reference by name
to other components, this assumption will in some
cases be violated if one or more references cannot be
resolved. This specification addresses the matter of
missing components in a uniform manner, described in
: no mention of handling missing
components will be found in the individual component
descriptions below.
Forward reference to named definitions and declarations
is allowed, both within and between
schema documents. By the time the component corresponding to
an XML representation which contains a forward reference is
actually needed for validation,
it is possible that an appropriately-named component
will have become available to discharge the reference: see
for details.
White Space Normalization during Validation
Throughout this specification, the
initial value of some
attribute information item is the value of the
normalized
value property of that item. Similarly, the initial value of an element information item is the string composed of, in order, the
character code of each character information item in the children of that
element information item.
The above definition means that comments and processing instructions,
even in the midst of text, are ignored for all validation purposes.
The
normalized value of an element or attribute
information item is an initial valuewhich has been normalized
according to the value of the whiteSpace facet, and the values of any other pre-lexical facets, associated with the simple type definition used
in its validation. The keywords for
whitespace normalization have the following meanings:
No normalization is done, the
whitespace-normalized value
is the initial value
All occurrences of #x9 (tab),
#xA (line feed) and #xD (carriage
return) are replaced with #x20
(space).
Subsequent to the replacements specified above under
replace, contiguous sequences of
#x20s are collapsed to a single
#x20, and initial and/or final
#x20s are deleted.
Similarly, the
normalized value of any string with respect to a
given simple type definition is the string resulting from
normalization using the whiteSpace facet
and any other pre-lexical facets, associated with that simple type definition.
When more than one pre-lexical facet applies, the whiteSpace facet is applied first; the order in which implementation-defined facets
are applied is implementation-defined.
If the simple type definition used in an item's
validation is xs:anySimpleType,
then the
normalized valuemust be determined
as in the preserve case above.
There are three alternative validation rules which help supply the necessary background for the
above: (), () or ().
These three levels of normalization correspond to the processing mandated
in XML for element content, CDATA attribute
content and tokenized
attributed content, respectively. See
Attribute Value Normalization
in for the precedent for replace and
collapse for attributes. Extending this processing to element
content is necessary to ensure
consistent validation
semantics for simple types, regardless of whether they are applied to attributes
or elements. Performing it twice in the case of attributes whose
normalized
value has already been subject to replacement or collapse on the basis of
information in a DTD is necessary to ensure consistent treatment of attributes
regardless of the extent to which DTD-based information has been made use of
during infoset construction.
Even when DTD-based information has been appealed
to, and Attribute Value
Normalization has taken place, it
is possible thatfurther normalization will
take place, as for instance when character entity references
in attribute values result in white space characters other than spaces
in their initial values.
The values replace and
collapse may appear to provide a
convenient way to unwrap text (i.e. undo the effects of
pretty-printing and word-wrapping). In some cases, especially
highly constrained data consisting of lists of artificial tokens
such as part numbers or other identifiers, this appearance is
correct. For natural-language data, however, the whitespace
processing prescribed for these values is not only unreliable but
will systematically remove the information needed to perform
unwrapping correctly. For Asian scripts, for example, a correct
unwrapping process will replace line boundaries not with blanks but
with zero-width separators or nothing. In consequence, it is
normally unwise to use these values for natural-language data, or
for any data other than lists of highly constrained tokens.
Attribute Declarations
Attribute declarations provide for:
Local validation of attribute information item values using a simple type definition;
Specifying default or fixed values for attribute information items.
The XML representation of an attribute declaration.
The Attribute Declaration Schema Component
The attribute declaration schema component has the following
properties:
The property must match the
local part of the names of attributes being validated.
The value of each attribute validatedmust conform to the supplied
.
A non-absent
value of the property provides for validation of namespace-qualified
attribute information items (which must be explicitly prefixed
in the character-level form of XML documents). Absent values of
validate unqualified (unprefixed)
items.
For an attribute declaration A, if A..
= global, then A is available for use throughout the schema.
If A..
= local, then A is available for use only within (the
or )
A...
Theproperty reproduces the functions of
XML default and
#FIXED attribute values. A of
default specifies that the attribute is to
appear unconditionally in the post-schema-validation infoset, with and used whenever the attribute is not
actually present; fixed indicates that the attribute
value if present mustbe equal to , and if absent receives and as for default. Note that
it is values that are checked, not
strings,
and that the test is for equality, not identity.
See for information on the role of the
property.
A more complete and formal presentation of the semantics of , and is provided in
conjunction with other aspects of complex type validation (see .)
distinguishes attributes with names such as xmlns or xmlns:xsl from
ordinary attributes, identifying them as namespace attributes. Accordingly, it is unnecessary and in fact not possible for
schemas to contain attribute declarations corresponding to such
namespace declarations, see . No means is provided in
this specification to supply a
default value for a namespace declaration.
XML Representation of Attribute Declaration Schema Components
The XML representation for an attribute declaration schema
component is an
element information item. It specifies a
simple type definition for an attribute either by reference or
explicitly, and may provide default information. The
correspondences between the properties of the information item and
properties of the component are given in this section.
Attribute declarations can appear at the top level of a schema
document, or within complex type definitions, either as complete
(local) declarations, or by reference to top-level declarations,
or within attribute group definitions. For complete
declarations, top-level or local, the type
attribute is used when the declaration can use a built-in or
pre-declared simple type definition. Otherwise an anonymous
is provided inline. When no simple type definition is
referenced or provided, the default is xs:anySimpleType, which
imposes no constraints at all.
Anelement
maps to an attribute declaration, and
allows the type definition of that declaration to be specified either by
reference or by explicit inclusion.
Top-level elements
(i.e. those which appear
within the schema document as
children of
elements) produce
globalattribute declarations;
s
within
or produce
either attribute uses which contain global attribute
declarations (if there's a ref attribute) or local
declarations (otherwise). For complete declarations, top-level or local,
the type attribute is used when the declaration can use a
built-in or user-defined global type definition. Otherwise an anonymous
is provided inline.
Attribute information items validated by a top-level
declaration must be qualified with the
of that
declaration. If the
is absent, the item must be
unqualified. Control over whether attribute
information items validated by a local declaration must be
similarly qualified or not is provided by the formattribute, whose default is provided by the
attributeFormDefaultattribute on the enclosing
, via its determination of
.
The names for top-level attribute declarations are in their
own symbol space. The
names of locally-scoped attribute declarations reside in symbol
spaces local to the type definition which contains them.
The following sections specify several
sets of XML mapping rules which apply in different
circumstances.
If the element information item
has as its parent, then it maps to
a
global as described in
.
If the element
information item has
or
as an ancestor, and the refattribute is
absent, and the useattribute is not
"prohibited", then it maps both to
an and to an
component, as described in
.
On components, see
.
If the element
information item has
or
as an ancestor, and the refattribute is
, and the useattribute is not
"prohibited", then it maps to
an
component, as described in
.
If the element information item
has use='prohibited', then it does not map to,
or correspond to, any schema component at all.
The use attribute is not allowed on
top-level elements, so
this can only happen with elements
appearing within a
or element.
Mapping Rules for Global Attribute Declarations
If the element information item has as its parent, the corresponding schema
component is as follows:
The actual value of the
nameattributeThe actual value of the
targetNamespaceattribute of the parent
element information item, or absent if there is none.The simple type
definition corresponding to the
element information
item in the children, if present, otherwise the simple
type definition resolved to by the actual value of the
typeattribute, if present, otherwise
xs:anySimpleType.A
as follows:globalabsentIf there is a
default or a fixedattribute,
then a as follows, otherwise absent.
either default or
fixed, as appropriatethe actual value (with respect
to the
) of theattributethe normalized value (with respect to the
) of the
attributeThe actual value
of the inheritableattribute, if present, otherwise
false. The of the
element, as defined in .
Mapping Rules for Local Attribute Declarations
If
the element information item has
or as
an ancestor and the refattribute is absent,
it mapsboth to an attribute
declaration (see below) and
to an attribute use with properties as follows
(unless use='prohibited', in which case the item
corresponds to nothing at all):
true if
the
element has use =
required, otherwise
false.See the Attribute Declaration mapping
immediately below.If there is a
default or a fixedattribute,
then a
as follows, otherwise absent.
either default
or fixed, as appropriatethe actual value of
theattribute(with respect to .)the normalized value of the attribute(with respect to .)The actual value
of the inheritableattribute, if present, otherwise
false.
The same annotations as the of
the Attribute Declaration. See below.
The element also
maps to the
of the attribute use, as follows:
The actual value of the
nameattribute
targetNamespace is present
its actual value.
targetNamespace is not present and
form
= qualified
form is absent and the ancestor has
attributeFormDefault =
qualified
the actual value of the targetNamespaceattribute of the ancestor
element information
item, or absent if there
is none.
absent.
The simple type
definition corresponding to the
element information
item in the children, if present, otherwise the simple
type definition resolved to by the actual value of the
typeattribute, if present, otherwise
xs:anySimpleType.A
as follows:localIf the element information item has as an ancestor, the corresponding to that item, otherwise (the
element information item is within an element information
item), the corresponding to
that item.absent.The actual value
of the inheritableattribute, if present, otherwise
false. The of the
element, as defined in .
Mapping Rules for References to Top-level Attribute Declarations
If
the
element information item has
or as an
ancestor and the refattribute is
present, it
maps to an attribute use with properties as follows
(unless use='prohibited', in which case the item
corresponds to nothing at all):
true if use =
required, otherwise
false.The (top-level)
attribute declaration resolved to by the actual value of
the refattributeIf there is a
default or a fixedattribute,
then a
as follows, otherwise absent.
either default
or fixed, as appropriatethe actual value of
theattribute(with respect to .)the normalized value of the
attribute(with respect to
.)The actual value
of the inheritableattribute, if present, otherwise
.. The of
the element, as defined in .
Constraints on XML Representations of Attribute Declarations
Attribute Declaration Representation OK
In addition to the conditions imposed on element
information items by the schema for schema documents,
default and fixedmust not both be present.
If default and use are both present,
usemust have the actual valueoptional.
If the item's parent is not , then
One of ref or nameis present, but not both.
If ref is present, then all of ,
form and typeare absent.
Thetypeattribute and achild elementmust not both be present.
If fixed and use are both present,
usemust not have the actual valueprohibited.
If thetargetNamespaceattribute
is present then
Thenameattribute
is present.
Theformattribute
is absent.
If the ancestor does not have a
targetNamespaceattribute or its actual value
is different from the actual value of targetNamespace of
, then
has as an ancestor
There is a ancestor
between the and the nearest
ancestor, and the actual value of the
baseattribute of
does not
the
name of xs:anyType.
Informally, an attribute in an XML
instance is locally valid
against an attribute declaration if and only if (a)
the name of the attribute matches
the name of the declaration, (b) after
whitespace normalization its normalized value is locally valid
against the type declared for the attribute, and
(c) the
attribute obeys any relevant value constraint. Additionally,
for xsi:type, it is required that the type named
by the attribute be present in the schema.
A logical prerequisite for checking the local validity of an
attribute against an attribute declaration is that the attribute
declaration itself and the type definition it identifies
both be present in the schema.
Local validity of attributes is
tested as part of schema-validity of attributes
(and of the elements on which they occur), and the result
of the test is exposed in the
property of the
post-schema-validation infoset.
A more formal statement
is given in the following constraint.
Attribute Locally Valid
For an attribute information item A
to be locally valid
with respect to an attribute declaration D
Dis notabsent
(see for
how this can fail to be the case)
and D and A have the same expanded name.
D.is notabsent.
A's initial valueis locally valid
with respect to D.
as per .
IfD. is present and D.. = fixed, then A's actual value
is equal toD...
If D is the built-in declaration for xsi:type
(), then A's actual valueresolves to a type definition.
Governing Attribute Declaration and Governing Type Definition
In a given schema-validity episode,
the declaration of an attribute
(its governing attribute declaration)
is the first of
the following which applies:
A declaration which was stipulated by the processor (see
).
Its context-determined declaration;
A declaration resolved to by its local
name and namespace
name,
provided the attribute
is not attributed to a skip
and the processor has not
stipulated a type definition at the start of .
If the attribute is attributed to a skip
or if the processor has
stipulated a type definition,
then it has no declaration.
The governing type definition of an
attribute, in a given schema-validity episode, is the
of the ,
unless the processor has stipulated another
type definition at the start of (see ), in which case it is the
stipulated type definition.
Schema-Validity Assessment (Attribute)
Schema-validity assessment of an attribute information item
involves identifying its and checking its
local validity against the declaration. If the
is not present in the schema, then assessment is necessarily
incomplete.
Schema-Validity Assessment (Attribute)
The schema-validity assessment of an attribute information item depends
on its localvalidation alone.
For an attribute information item's schema-validity to have been assessed
A non-absent
attribute declaration
is known for it, namely its
declaration.
Its localvalidity with respect to that
declaration
has
been evaluated as per .
Both and of are satisfied.
For
attribute information items,
there is no difference between assessment and strict
assessment, so
the attribute information item has
been strictly assessed
if and only if its schema-validity has been assessed.
Attribute Declaration Information Set Contributions
Assessment Outcome (Attribute)
Assessment Outcome (Attribute)
If the schema-validity of an attribute information item has been assessed
as per , then in the post-schema-validation infoset it
has properties as follows:
The nearest ancestor element
information item with a
property.
it was strictly assessed
it was locallyvalid
as defined by
valid;
invalid.
notKnown.
it was strictly assessed
full;
none.
infoset. See for the other possible value.
Validation Failure (Attribute)
Validation Failure (Attribute)
If and only if the local validity, as defined
by
above, of an attribute information item has been assessed,
then in the post-schema-validation infoset the item
has a property:
the item is invalid
a list. Applications wishing to provide
information as to the reason(s) for the validation failure are encouraged to record one or more
error codes (see ) herein.
absent.
Attribute Declaration
Attribute Declaration
If and only if a
declaration is known for an attribute information
item
then in the post-schema-validation infoset the attribute information item
has a
property:
An item isomorphic to the
declaration component itself.
If the attribute information item is attributed to an
then the
of the effective value constraint,
otherwise the of the
declaration's .
Attribute Validated by Type
Attribute Validated by Type
If and
only if a
is known for
an attribute information
item,
then in the post-schema-validation infosetthe
attribute information itemhasthe
properties:
If the
attribute's normalized value is
valid with respect to the ,
then thenormalized value as validated, otherwise
absent.
If the
is not
absent, then the corresponding
actual value; otherwise absent.
An item isomorphic to
the
component.simple.The of the type
definition.true
if theof the type
definition is absent,
otherwise false.The of the
type definition, if the
is not absent. If the
type definition's
property is absent, then
schema processors may, but need
not, provide a value which uniquely identifies this
type definition among those with the same target namespace.
It is
implementation-defined whether a processor provides a name
for such a type definition. If a processor does provide a value in this
situation, the choice of what value to use is implementation-dependent.
The
type definition type,
type definition namespace,
type definition name, and
type definition anonymous properties
are redundant with the
type definition property;
they are defined for the convenience of implementations
which wish to expose those specific properties
but not the entire type definition.
If
the attribute'sinitial value is valid with respect to the
as defined by andthe has union, then calling that basic
member of its transitive
membership which actually validated the attribute item's normalized value the
actual member type definition, there arefour additional properties:
an item isomorphic to
the .
The of the actual
member type definition.true if the of the actual member
type definition is absent,
otherwise false.The of the actual member type
definition, if it is not absent. If it is absent, schema processors may, but need
not, provide a value unique to the definition.
It is
implementation-defined whether a processor provides a name
for such a type definition. If a processor does provide a value in this
situation, the choice of what value to use is implementation-dependent.
The first (item isomorphic)
alternative
above is provided for applications such as query
processors which need access to the full range of details about an
item's , for example the
type hierarchy; the second, for lighter-weight processors for whom
representing the significant parts of the type hierarchy as
information items might be a significant burden.
If
the attribute's normalized value is valid with respect to the
;
the has =list;
the has =union and the has
=list;
the of the list type
(from the previous clause) has =union;
then there is an additional property:
a sequence of components, with the same length as the
, each one an
item isomorphic to the
basic member which
actually validated the corresponding
space-delimited substring in the .
See also
,
and ,
which describe
other information set contributions related to attribute information items.
Constraints on Attribute Declaration Schema Components
All attribute declarations (see ) must satisfy the following constraints.
The values of the properties of an attribute declaration are as described in
the property tableau in , modulo the impact
of .
if there is a , thenit is a valid default with respect
to the as
defined in .
The use of ID and related
types together with value constraints goes beyond what is possible with
XML DTDs, and should be avoided if compatibility with DTDs is desired.
Simple Default Valid
Simple Default Valid
For a
Value Constraint Vto be
a valid default with respect to a T
V.isvalid with
respect to T
as defined by
Datatype
Valid in .
V.
maps to V.
in the
value space of T.
xmlns Not Allowed
xmlns Not Allowed
The of an attribute declaration must not match xmlns.
The of an attribute is an NCName, which implicitly
prohibits attribute declarations of the form xmlns:*.
xsi: Not Allowed
xsi: Not Allowed
The of an attribute declaration,
whether local or top-level, must not match http://www.w3.org/2001/XMLSchema-instance
(unless it is one of the four built-in declarations given in the next section).
This reinforces the special status of these attributes, so that they not
only need not be declared to be allowed in instances, but
in consequence of the rule just givenmust not be declared.
It is legal for s that
refer to xsi: attributes to specify default or fixed value
constraints (e.g. in a component corresponding to a schema document construct
of the form <xs:attribute ref="xsi:type" default="xs:integer"/>),
but the practice is not recommended; including such attribute uses will tend
to mislead readers of the schema document, because the attribute uses would
have no effect; see and
for details.
Built-in Attribute Declarations
There are four attribute declarations present in every
schema by definition:
xsi:type
The xsi:type attribute
is used to signal use of a type other than the declared type of
an element. See .
Attribute Declaration for the 'type' attribute
typehttp://www.w3.org/2001/XMLSchema-instanceThe built-in QName simple
type definitionA as follows:
globalabsentabsentthe empty sequencexsi:nil
The xsi:nil attribute
is used to signal that an element's content is nil
(or null). See .
Attribute Declaration for the 'nil' attribute
nilhttp://www.w3.org/2001/XMLSchema-instanceThe built-in boolean simple
type definitionA as follows:
globalabsentabsentthe empty sequencexsi:schemaLocation
The xsi:schemaLocation attribute
is used to signal possible locations of relevant schema documents.
See .
Attribute Declaration for the 'schemaLocation' attribute
schemaLocationhttp://www.w3.org/2001/XMLSchema-instanceAn anonymous simple type definition, as follows:
absenthttp://www.w3.org/2001/XMLSchema-instanceThe built in xs:anySimpleTypeabsentlistThe built-in anyURI simple
type definitionthe empty sequenceA as follows:
globalabsentabsentthe empty sequencexsi:noNamespaceSchemaLocation
The xsi:noNamespaceSchemaLocation attribute
is used to signal possible locations of relevant schema documents.
See .
Attribute Declaration for the 'noNamespaceSchemaLocation' attribute
noNamespaceSchemaLocationhttp://www.w3.org/2001/XMLSchema-instanceThe built-in anyURI simple
type definitionA as follows:
globalabsentabsentthe empty sequence
Element Declarations
Element declarations provide for:
Local validation of element information item values using a type definition;
Specifying default or fixed values for element information items;
Establishing uniquenesses and reference constraint relationships among the values of related elements and
attributes;
Controlling the substitutability of elements through the
mechanism of element substitution groups.
XML representations of several different types of element declaration
The Element Declaration Schema Component
The element declaration schema component has the following
properties:
The propertymust match the
local part of the names of element information items being
validated.
For an element declaration E, if E..
= global, then E is available for use throughout the schema.
If E..
= local, then E is available for use only within (the
or )
E...
A non-absent
value of the property provides for validation of namespace-qualified
element information items. Absent values of
validate unqualified items.
An element information item is normally
required to satisfythe . For such an
item, schema information set
contributions appropriate to the are added to the
corresponding element information
item in the post-schema-validation infoset. The type
definition against which an element information item is
validated (its
) can be different from the
declared . The property of an , which governs conditional type assignment, and
thexsi:type attribute of an element information item
(see ) can cause the and the
declared to be different.
If is true, then
an element with no text or element
contentcan be valid
despite a
which would otherwise require
content, if it carries the
attribute xsi:nil with the value
true (see ).
Formal details of element validation are described in
.
An
element information item E is nilled
with respect to some element declaration D if and only if
E has xsi:nil = true.
D. = true.
If E is said to be without the
identity of D being clear from the context, then D is assumed to
be E's .
establishes a
default or fixed value for an element. If a
with
=default is present, and if the element being validated is
empty, then for
purposes of calculating the
and other contributions to the post-schema-validation infosetthe element is
treated as if
.was
used as the content of the element. If fixed
is specified, then the element's content must either be empty,
in which case fixed behaves as default, or its
value mustbe equal to..
When a default value is supplied and used, as described in
the second sentence of the preceding paragraph, the default
value is used to calculate the
, etc.,
but the actual content of the element is not changed: the
element contained no character information items in the input
information set, and it contains none in the PSVI.
The provision of defaults for elements goes beyond what is
possible in XML DTDs,
and does not exactly correspond to defaults for attributes. In
particular, an element with a non-empty whose simple type definition includes the empty
string in its lexical space will nonetheless never receive that
value, because the will override it.
express
constraints establishing uniquenesses and reference
relationships among the values of related elements and
attributes. See .
The
property of an element declaration indicates
which substitution groups, if any, it can potentially be a member of.
Potential membership is transitive but not
symmetric; an element declaration is a potential member of any
group named in its , and
also of any group of which any entry
in its is a potential member. Actual
membership may be blocked by the effects of or , see below.
An empty allows a declaration to be named in the of other
element declarations having the same declared or
some typederived therefrom.
The explicit values of ,
extension or restriction,
rule out element declarations having
types whose
derivation from involves any
extension steps, or restriction steps,
respectively .
The supplied values for determine whether an element declaration
appearing in a content
model will be prevented from additionally validating elements (a) with an
that identifies an extension
or restriction of the type of the declared element,
and/or (b) from validating
elements which are in the headed by the declared
element. If
is empty, then
all derived types and members are allowed.
Element declarations for which is true can appear in content models
only when substitution is allowed; such declarations must not themselves ever be used to
validate element content.
See for information on the role
of the property.
XML Representation of Element Declaration Schema Components
The XML representation for an element declaration schema
component is an element information
item. It specifies a type definition for an element either by
reference or explicitly, and may provide occurrence and
default information. The correspondences between the properties
of the information item and properties of the component(s) it
corresponds to are given in this section.
Anelement
information item in a schema documentmaps to an
element declaration and allows the
type definition of that declaration to be specified either by
reference or by explicit inclusion.
Top-level
elements
(i.e. those which appear within
the schema document as children of
elements)
produce
global element declarations; s within or produce either particles which contain global element declarations (if there's a ref attribute) or local declarations (otherwise). For complete declarations, top-level or local, the type attribute is used when the declaration can use a
built-in or
user-defined global type definition. Otherwise an
anonymous or is provided inline.
Element information items validated by a top-level
declaration must be qualified with the
of that
declaration.
If the
is absent,
the item must be unqualified.
Control over whether element information items validated by a local declaration must be similarly qualified or not
is provided by the formattribute, whose default is provided
by the elementFormDefaultattribute on the enclosing , via its determination of .
The names for top-level element declarations are in a separate
symbol space from the symbol spaces for
the names of type definitions, so there can (but need
not be) a simple or complex type definition with the same name as a
top-level element. The names of locally-scoped
element declarations need not be unique and thus
reside in no symbol space at all (but the element declarations are
constrained by ).
Note that the above allows for two levels of defaulting for unspecified
type definitions. An with no referenced or included type definition will
correspond to an element declaration which has
the
same type definition as the first
substitution-group head named in the
substitutionGroupattribute, if present,
otherwise xs:anyType.
This has the important consequence that the minimum valid element declaration,
that is, one with only a name attribute and no contents,
is also (nearly) the most general, validating any combination of text and
element content and allowing any attributes, and providing for recursive
validation where possible.
See
for , and .
The following sections specify several
sets of XML mapping rules which apply in different circumstances.
If the element information item has
as its parent, it maps to
an using the mappings described in
and
.
If the element information
item has
or as an ancestor,
and the refattribute is absent,
and it does not have minOccurs=maxOccurs=0,
then it maps both to a , as described
in , and also to an
, using the mappings described in
and
.
If the element information item has
or as an
ancestor, and the refattribute is present,
and it does not have minOccurs=maxOccurs=0,
then it maps to a
as described in .
If the element information item has
minOccurs=maxOccurs=0,
then it maps to no component at all.
The minOccurs and maxOccurs
attributes are not allowed on top-level
elements, so in valid schema
documents this will happen only when the element information item has
or as an
ancestor.
Common Mapping Rules for Element Declarations
The following mapping rules apply
in all cases where an element
maps to an component.
The actual value of the
nameattribute.The first of the following
that applies:
The type definition corresponding to the or
element information item in the
children, if either is present.
The type definition resolved to by the actual value of
the typeattribute, if it is present.
The declared
of the resolved to by the first
QName in the actual value of the
substitutionGroupattribute, if present.
xs:anyType.
A
corresponding to the element
information
items among the children, if any, as follows, otherwise
absent.
A sequence of s, each corresponding, in
order, to one of
the elements which have a
testattribute.
Depends upon the final element among the
children. If it has no testattribute, the final maps to
the ;
if it does have a test attribute, it is covered by
the rule for and
the
is taken from the declared type of the .
So the value of the
is given by
the has no testattribute
a corresponding to the .
(the has a
test) a with the following properties: absent.the property of
the parent .the empty sequence.
The actual value of the
nillableattribute, if present, otherwise
false.If there is a
default or a fixedattribute,
then a as follows, otherwise absent. Use the name effective simple type
definition for the declared , if it is a
simple type definition,
or, if .. = simple,
for ..,
or else for the built-in
string simple
type definition).either default or
fixed, as appropriatethe actual value (with respect
to the ) of theattributethe normalized value (with respect to the ) of the attributeA set
consisting of the identity-constraint-definitions corresponding to
all the ,
and element
information items in the children, if any, otherwise the
empty set.A set of the element declarations
resolved to by the items in the actual value of the
substitutionGroupattribute, if present,
otherwise the empty set.A set
depending on the actual value of the blockattribute, if present, otherwise on the actual value of the
blockDefaultattribute of the ancestor
element information item, if present,
otherwise on the empty string. Call this the
EBV (for effective block value). Then the
value of this property is
the EBV is the empty string
the empty set;
the EBV is #all
{extension,
restriction,
substitution};
a set with members drawn from the set
above, each being present or absent depending on whether
the actual value (which is a list) contains an equivalently
named item.
Although the blockDefaultattribute of
may include values other than
extension, restriction or
substitution, those values are ignored in the
determination of for element
declarations (they are used elsewhere).
As for
above,
but using the final and finalDefaultattributes in place of the block and
blockDefaultattributes and with the relevant
set being {extension,
restriction}.The actual value of the
abstractattribute, if present, otherwise
false. The of the
element
and any of its , and
children with a refattribute, as defined in .
Mapping Rules for Top-Level Element Declarations
If the element information item has
as its parent,
it
maps to a
global, using the mapping given
in ,
supplemented by the following.
The actual value of the
targetNamespaceattribute of the parent
element information item, or absent if there is none.A
as followsglobalabsent
Mapping Rules for Local Element Declarations
If
the element information
item has
or as
an ancestor,
and the refattribute is absent,
and it does not have
minOccurs=maxOccurs=0,then it maps both to a
and to a local
which is the
of that . The
is as follows:
The actual value of the
minOccursattribute, if present, otherwise
1.unbounded, if the
maxOccursattribute equals
unbounded, otherwise the actual value of the
maxOccursattribute, if present, otherwise
1.A (local) element declaration as
given below.
The same annotations as the of the .
The
element also maps to an
element declaration using the
mapping rules given in
, supplemented by those
below:
targetNamespace is present
its actual value.
targetNamespace is not present and
form=qualified
form is absent and the
ancestor
has elementFormDefault =qualified
the actual value of the targetNamespaceattribute
of the ancestor element
information item,
or absent if there is
none.
absent.
A
as follows:localIf the element information item has as an ancestor, the corresponding to that item, otherwise (the
element information item is within a named element information
item), the corresponding to
that item.
References to Top-Level Element Declarations
If the element information
item has
or as an
ancestor,
and the refattribute is
present,
and it does not have
minOccurs=maxOccurs=0,then it maps to
a as follows.
The actual value of the
minOccursattribute, if present, otherwise
1.unbounded, if the
maxOccursattribute equals
unbounded, otherwise the actual value of the
maxOccursattribute, if present, otherwise
1.The (top-level) element
declaration resolved to by the actual value of the
refattribute. The of
the element, as defined in .
Examples of Element Declarations
<xs:element name="unconstrained"/>
<xs:element name="emptyElt">
<xs:complexType>
<xs:attribute ...>. . .</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="contextOne">
<xs:complexType>
<xs:sequence>
<xs:element name="myLocalElement" type="myFirstType"/>
<xs:element ref="globalElement"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="contextTwo">
<xs:complexType>
<xs:sequence>
<xs:element name="myLocalElement" type="mySecondType"/>
<xs:element ref="globalElement"/>
</xs:sequence>
</xs:complexType>
</xs:element>
The first example above declares an element whose type, by default, is
xs:anyType.
The second uses an embedded anonymous complex
type definition.
The last two examples illustrate the use of local element declarations. Instances of myLocalElement within
contextOne will be constrained by myFirstType,
while those within contextTwo will be constrained by
mySecondType.
The possibility that differing attribute declarations and/or content models
would apply to elements with the same name in different contexts is an
extension beyond the expressive power of a DTD in XML.
An example from a previous version of the schema for datatypes. The
facet type is defined
and the facet element is declared to use it. The facet element is abstract -- it's
only defined to stand as the head for a . Two further
elements are declared, each a member of the facet. Finally a type is defined which refers to facet, thereby
allowing eitherperiod or encoding (or
any other member of the group).
The following example illustrates conditional type assignment
to an element, based on the value of one of the element's attributes.
Each instance of the message element will be
assigned either to type messageType or to a more
specific type derived from it.
The type messageType accepts any well-formed XML
or character sequence as content, and carries a kind
attribute which can be used to describe the kind or format of
the message. The value of kind is either one of a
few well known keywords or, failing that, any string.
Three restrictions of messageType are defined, each
corresponding to one of the three well-known formats:
messageTypeString for kind="string",
messageTypeBase64 for kind="base64"
and kind="binary", and
messageTypeXML for kind="xml" or
kind="XML".
The message element itself uses
messageType both as its declared type and
as its default type, and uses test attributes on its
children to assign the appropriate
specialized message type to messages with the well known
values for the kind attribute.
Because the declared type and the default type are the same, the last
(without the test attribute)
can be omitted.
<xs:element name="message" type="messageType">
<xs:alternative test="@kind='string'" type="messageTypeString"/>
<xs:alternative test="@kind='base64'" type="messageTypeBase64"/>
<xs:alternative test="@kind='binary'" type="messageTypeBase64"/>
<xs:alternative test="@kind='xml'" type="messageTypeXML"/>
<xs:alternative test="@kind='XML'" type="messageTypeXML"/>
<xs:alternative type="messageType"/>
</xs:element>
Constraints on XML Representations of Element Declarations
Element Declaration Representation OK
In addition to the conditions imposed on element
information items by the schema for schema documents:
default and fixedare not
both present.
If the item's parent is not , then
One of ref or nameis present, but not both.
If ref is present, then all of ,
, , ,
, nillable, default,
fixed, form, block and typeare absent,
i.e. only minOccurs, maxOccurs, idand are
allowed to appear together withref.
The element does not have both a
or child and a
type attribute.
If targetNamespace is present then
name is present.
form is not present.
If the ancestor does not have a
targetNamespaceattribute or its actual value
is different from the actual value of targetNamespace of
, then
has as an ancestor
There is a ancestor
between the and the nearest
ancestor, and the actual value of the
baseattribute of
does not
the
name of xs:anyType.
Every element but
the last has a testattribute; the last
element may have such an attribute.
Element Declaration Validation Rules
When an element is assessed, it is
first checked against its , if any; this in turn
entails checking it against its . The
second step is recursive: the element's attributes and children are
assessed in turn with respect to the declarations assigned to
them by their parent's .
Selected and Instance-specified Type Definitions
The of an element
is normally the declared associated with the
, but this may be overridden using conditional type assignment in the or using an , or both.
When the element is declared with
conditional type assignment, the is used as the
unless overridden by an .
The selected type
definitionS of an element information item E is a
type definition associated with E in the following way. Let
D be the of E. Then:
If D has a , then S is the type conditionally selected for
E by D..
If
D has no , then S is D..
If E has no , then E has no selected
type definition.
It is a consequence of
that if D is valid, then
S will be for D's
declared , or else that S will be
xs:error.
Given a T and an element
information item E, Tconditionally selects a
type S for Ein
the following way. The
expressions in T's are evaluated, in order,
until one of the s a type definition for E, or until
all have been tried without success. If any
a type definition, none of the following
s are tried. Then the type Sconditionally
selected for E by T is
as described in
If at least one in T. a type definition for E, then S
is the type definition selected by the first such .
If no in T.
a type definition, then S is
T...
An instance-specified type definition
is a type definition associated with an element information
item in the following way:
Among the element's attribute information items is one
named xsi:type.
The normalized value of that attribute information item is a
qualified name valid with
respect to the built-in QName simple type, as
defined by .
The
actual value (a )
resolves
to a type definition.
It is this type definition which is the
instance-specified type definition.
Type Override and Valid Substitutability
An S is said to
override another type definition T if and only
if all of the following are true:
S is the
on some element information item
E. A may or may not be known for E.
S is for T, subject to the blocking keywords of
the of
E's , if any, or validly
substitutable without limitation for
T (if no is known).
Typically, T
would be the for E if it were not
overridden. (This will be the case if T was stipulated by
the processor, as described in , or E has a and
T is its declared type, or T is the
of E.)
The use of the term
to denote the relation between an S and another type T has nothing to do with the
element; the two mechanisms are
distinct and unrelated.
A type definition S is
validly substitutable for another type T,
subject to a
set of blocking keywordsK (typically drawn from the set
{substitution, extension,
restriction, list, union} used in
the and
of
element declarations and type definitions), if and
only if either
S and T are both complex
type definitions and S is validly derived from Tsubject tothe
blocking keywords in the union of K and T.,
as defined in
or
S is a complex type definition, T is a
simple type definition, and S is validly derived from
Tsubject tothe
blocking keywords inK, as defined in
or
S is a simple type definition and S is
validly derived from Tsubject tothe blocking keywords inK, as defined in .
If the set of keywords controlling whether
a type S is for another type T is the
empty set, then S is said to be validly
substitutable for Twithout limitation
or absolutely. The phrase validly
substitutable, without mention of any set of blocking
keywords, means validly substitutable without
limitation.
Sometimes one type S is
for another type T only if S is derived
from T by a chain of restrictions, or if T is a union type
and S a member type of the union. The concept of valid substitutability is
appealed to often enough in such contexts that it is convenient
to define a term to cover this specific case. A type definition S is validly
substitutable as a restriction for another type T if
and only if S is for T, subject to the
blocking keywords {extension, list,
union}.
Element Locally Valid (Element)
The concept of local validity of an
element information item against an element declaration is
an important part of the schema-validity
of elements. (The other important part is the recursive
of attributes and descendant elements.)
Local validity partially determines the element information item's
property,
and fully determines the
property, in the post-schema-validation infoset.
Informally, an element is locally valid
against an element declaration when:
The declaration is present in the schema
and the name of the element matches the name of the declaration.
The element is declared concrete (i.e. not abstract).
Any xsi:nil attribute on the element obeys the
rules. The element is allowed to have an xsi:nil
attribute only if the element is declared nillable, and
xsi:nil = 'true' is allowed only if the element
itself is empty. If the element declaration specifies a
fixed value for the element, xsi:nil='true'
will make the element invalid.
Any xsi:type attribute present names a
type which is for the element's
declared .
The element's content satisfies the appropriate constraints:
If the element is empty and the declaration specifies a
default value, the default is checked against the
appropriate type definitions.
Otherwise, the content of the element is checked against
the ; additionally, if the element
declaration specifies a fixed value, the content is
checked against that value.
The element satisfies all the identity constraints specified
on the element declaration.
Additionally, on the , document-level
ID and IDREF constraints are checked.
The following validation rule gives
the normative formal definition of local validity of an element
against an element declaration.
Element Locally Valid (Element)
For an element information item E to be locally valid with respect to an element
declaration D
Dis notabsent
and E and D have the same expanded name.
D.=false.
D.=false,
and E has no
xsi:nil attribute.
D.=true
and
E has no xsi:nil
attribute information item.
E has xsi:nil = false.
E has xsi:nil
= true
(that is, E is ), and
E has no character or element
information item children.
D
has no with
=fixed.
If E has anxsi:typeattribute, then
E has an which is not
absent.
The is
for the
of E, subject tothe blocking keywords
inD..
That is, the overrides the .
If an
exists and overrides the , then the
of E is the , otherwise it is the .
D has a , andE has neither
element nor character children, and
E is not
with respect to D
If
E's
is
an ,
then
D.is a valid default for the
as defined in .
The element information item with
D..
used as its normalized valueislocallyvalid with respect to
the as defined
by .
D has no , or E has either element or
character children, or E is
with respect to D
Eislocallyvalid with respect to the
as defined
by .
If D.. = fixed and
E
is not with respect to D, then
Ehas no element
information item children.
E's is a
with . = mixed
the initial
value of EmatchesD...
E's
is a
or a with
. = simple
the actual value of Eis equal toD...
Eisvalid with respect to each of the
as per .
If E is the ,
then it isvalid per .
If an element has an xsi:type attribute whose
value does not resolve to a type definition,
or if
the type definition fails tooverride the , then theof its
becomes the. The local validity of the element
with respect to the is recorded in the
property.
Element Locally Valid (Type)
The following validation rule specifies
formally what it means for an element to be locally valid
against a type definition. This concept is appealed to in the
course of checking an element's local validity against its
. It
is also part of schema-validity
of an element when the element is
laxly assessed, by checking its local validity
against xs:anyType.
Informally, local validity against a type requires first
that the type definition be present in the schema and not declared abstract.
For a simple type definition, the element must lack attributes
(except for namespace declarations and the special attributes
in the xsi namespace) and child elements, and must
be type-valid against that simple type definition.
For a complex type definition, the element must
be locally valid against that complex type definition.
Also, if the element has an xsi:type attribute,
then it is not locally valid against any type other than the
one named by that attribute.
Element Locally Valid (Type)
For an element information item E
to be locally valid with respect to
a type definition T
Tis notabsent;
If T is a complex type definition, then
T. = false.
T is a simple type
definition
E.attributes
is empty, except for attributesnamed xsi:type,
xsi:nil,
xsi:schemaLocation, or
xsi:noNamespaceSchemaLocation.
Ehas no element
information item children.
If E is not , then the initial valueisvalid with
respect to T as defined by .
T is a complex type
definition
Eislocallyvalid with respect to T
as per ;
If E has an
xsi:typeattribute and does
not have a , then the actual value of
xsi:typeresolves to T.
This rule only covers the case when a is not available.
When a is present, the same rule is checked
in
of .
Validation Root Valid (ID/IDREF)
The following validation rule
specifies document-level ID/IDREF constraints checked on the
if it is an element; this rule is not checked on other
elements. Informally, the requirement is that each ID
identifies a single element within the ,
and that each IDREF value matches one ID.
Validation Root Valid (ID/IDREF)
For an element information item E
which is the
to be valid
There is no ID/IDREF binding in
E. whose is the empty set.
There is no ID/IDREF binding in
E. whose
has more than one
member.
See for the definition of
ID/IDREF binding.
The first clause above applies when there is a reference to an undefined
ID. The second applies when there is a multiply-defined ID. They
are separated out to ensure that distinct error codes (see
) are associated with these two
cases.
Although this rule applies at the , in
practice processors, particularly streaming processors,
will perhaps wish to detect and signal the
case as it arises.
This reconstruction of 's
ID/IDREF functionality is imperfect in that if
the is not the document element of an XML
document, the results will not necessarily be the same as
those a validating parser would give were the document to have
a DTD with equivalent declarations.
Schema-Validity Assessment (Element)
This section gives the top-level rule
for of an element information item. Informally:
Assessment begins with the identification of a
for the element and then checks that the
element is locally valid against the declaration; if no
is available, a can be
used instead.
The element's attributes are to be assessed recursively,
unless they match a skip wildcard and are thus
.
The element's children are to be assessed recursively,
unless they match a skip
wildcard and are thus . For each child element,
the is the one identified in the course
of checking the local validity of the parent, unless that
declaration is not available. If the is not
available, the element may still be
if a can be identified (e.g. via the
xsi:type attribute), otherwise the element
will be laxly assessed.
The governing element declaration of
an element information itemE,
in a given schema-validity
episode, is the first of the following
which applies:
A
declaration stipulated by the processor (see ).
E'scontext-determined
declaration.
A declaration resolved
to by E's local name
and namespace
name, provided that E
is attributed either to a strict
or to a lax.
A declaration resolved to by
E'slocal
name and namespace
name, provided that
none of the following is true:
E is attributed to
a skip
the
processor has stipulated a type definition for
E
a non-absent exists for
E
If none of these apply,
E has
no (or, in equivalent words,
E's is absent).
The governing type definition of an
element information itemE,
in a given schema-validity episode, is the first of the following which
applies:
An which overrides a type
definition stipulated by the processor (see ).
A type definition stipulated by the processor (see
).
An which overrides the of E.
The of E.
The valueabsent
if E is .
An which overrides the .
The .
An
.
If none of these apply, there is no
(or, in equivalent words, it is absent).
Schema-Validity Assessment (Element)
The schema-validity assessment of an element information item
E is performed as follows:
If E has a or a ,
then Emust be .
If E is ,
then Emust not be assessed.
Otherwise, Emust be laxly assessed.
An element
information item E is said to be strictly assessed
if and only if
A non-absent element declaration
is known for E, namely its
declaration.
E'slocalvalidity with
respect to that declaration has been evaluated as per
.
If that evaluation involved the evaluation of
, thereof is satisfied.
E does not have a .
A non-absent
type definition is known for E, namely its
The localvalidityof E with respect to its
has been evaluated as
per .
For each of the attribute information items among
E.attributes,
the attribute has a
its schema-validity is assessed with respect to that
declaration, as defined in .
its schema-validity is not assessed.
For each of the element information items among its
children,
the child has a or a
its schema-validity is assessed with respect to that
declaration or type definition, as defined in .
the child is a skip
its schema-validity is not assessed.
its schema-validity is laxly assessed with
respect to xs:anyType.
The schema validity of an element information item E is
said to be laxly assessed if and only if
E has neither a
nor a .
E is locallyvalidated with respect to
xs:anyType as defined in
, and the schema-validity of
E's attributes and children
is assessed as described in and
of .
It follows from the definitions given that no element
information item can be both
and laxly assessed in the same schema-validity
episode.
Element Declaration Information Set Contributions
Assessment Outcome (Element)
Assessment Outcome (Element)
If and only if the schema-validity of an element information item
has been assessed as per , then
in the post-schema-validation infoset it has properties as follows:
The nearest ancestor element
information item with a property (or this element item
itself if it has such a property).
it was
of applied and the item was
locallyvalid as defined by
;
of applied and the item was
locallyvalid as defined by
.
Neither its children nor its attributes
contains an information item (element or attribute
respectively) whose validity is
invalid.
Neither its children nor its attributes
contains an information item (element or attribute
respectively) which is attributed to a
strict and whose
validity is
notKnown.
valid;
invalid.
notKnown.
it was and neither its children nor its
attributes contains an information item (element or
attribute respectively) whose validation attempted is not
full
full;
it was not and neither its children nor its
attributes contains an information item (element or
attribute respectively) whose validation attempted is not
none
If and only if the local validity,
as defined by
above and/or below,
of an element information item has been assessed, then in the post-schema-validation infoset the item
has a property:
the item is invalid
a list. Applications wishing to provide
information as to the reason(s) for the validation failure are encouraged
to record one or more error codes (see ) herein.
absent.
the element information item is locally
invalid, because unexpected
attributes or elements were found among its attributes
and children
of
would be
satisfied, if those unexpected attributes and
children (those with = none) were removed
true
false
A list of s that are
not satisfied
by the element information item, as defined by .
In
principle, the value of this property includes all of the
s which are not satisfied for this element item;
in practice, some processors will expose a subset of the
items in this value, rather than the full value.
For example, a processor could choose not to check
further identity constraints after detecting the first
failure.
A list of s that are not
satisfied by the element information item, as defined by .
In
principle, the value of this property includes all of the
s which are not satsfied by this element item;
in practice, some processors will expose a subset of the items in this
value, rather than the full value. For example, a processor
could choose not to check further assertions after detecting the first
failure.
Element Declaration
Element Declaration
If and only ifa is known
for an element information item, then in the post-schema-validation infoset the element
information item has the properties:
an item isomorphic to the
declaration
component itselftrue if
of above is satisfied,
otherwise falseif the element information item is
attributed to an , then the of that , otherwise absent
The either is the
same as or is in the of the .
an item isomorphic
to the declared of the
the item was locallyvalid as defined by
valid
(the item was
locallyinvalid as defined by ) invalid.
Element Validated by Type
Element Validated by Type
If and only if a
is known for an element
information item, then in the post-schema-validation infoset the item hasthe properties:
the element information item is not and either the
is a simple type definition or its
has
simple
of
above has applied
the of the
of above has
not applied and the the element's initial value
is valid with respect to the simple
type definition as defined by
the normalized value of the item as validated
absent.
absent.
If the is not
absent, then the corresponding actual value
; otherwise
absent.
An item isomorphic to
the component
itself.simple or complex, depending on the ..target namespace.true
if
.name
is absent, otherwise
false.If .name is not absent, then
.name, otherwise
schema processors may, but
need not, provide a value unique to the definition. It
is implementation-defined whether a processor provides a name for
such a type definition. If a processor does
provide a value in this situation, the choice of what value
to use is implementation-dependent.A keyword indicating whether the expected type
definition was unavailable and the element had a fallback type
as its
declared if the element information item has a which has no ,
and also an
xsi:type attribute which fails to resolve to
a type definition that overrides the
declared
selected if the
element information item has a with a
and also has an xsi:type
attribute which fails to resolve to a type
definition that overrides the
lax if the
element was laxly assessed
using xs:anyType
none otherwise
If the element's does not
have a , then absent; otherwise the first that
successfully selected the
element's , if any; otherwise the .
the element information item was locallyvalid as defined by
valid
(the item was locallyinvalid as defined by ) invalid.
neither its children nor its attributes contains an
information item I (element or attribute
respectively) where either I's is invalid or
I is attributed to a strict
and I's
is notKnown
valid;
invalid.
The type definition
type, type definition
namespace, type
definition name, and type definition anonymous
properties are redundant with the type definition property; they are
defined for the convenience of implementations which wish to
expose those specific properties but not the entire type
definition.
When of above
applies and the default or
fixed value constraint is of type QName or NOTATION, it is implementation-dependent whether
occurs;
if it does not, the prefix used in the lexical representation
(in ) will not
necessarily map to the namespace name of the value (in ). To reduce problems and confusion, users may
prefer to ensure that the required namespace information item
is
present in the input
infoset.
If the
is not
absent and the
is
a simple type definition with
union,
or its has simple and a simple type definition withunion, then calling
that basic
member of its transitive
membership which actually validated the the
actual member type definition, there
are four additional
properties:
An item
isomorphic to the The of the actual member type
definition.true if the
of the actual member type definition is
absent, otherwise
false.The of the actual member
type definition, if it is not absent. If it is absent, schema processors may, but
need not, provide a value unique to the definition. It
is implementation-defined whether a processor provides a name for
such a type definition. If a processor does
provide a value in this situation, the choice of what value
to use is implementation-dependent.
The
property is provided for applications such as query
processors which need access to the full range of details about
an item's , for
example the type hierarchy; the ,
,
, and
properties are defined
for the convenience of those specifying
lighter-weight interfaces, in which
exposing the entire type hierarchy and full component details
might be a significant
burden.
If
the is not
absent;
the simple type definition used to validate the
normalized value (either the or its
) has =list;
the simple type definition has =union and the
has
=list;
the of the list
type (from the previous clause) has =union;
then there is an additional property:
a sequence of components, with the same length
as the
, each one an
item isomorphic to the
basic
member which actually validated the corresponding
space-delimited substring in the .
Also, if the declaration has a , the item has a property:
The
of the declaration's .
Note that if an element is laxly assessed, then the and
properties, or
their alternatives, are based on xs:anyType.
Element Default Value
Element Default Value
If and only if the local validity,
as defined by above, of an element
information item has been assessed, in the post-schema-validation infoset the item
has a property:
of above applies
schema.
infoset.
See also ,
, ,
and
, which describe other information set contributions
related to element information items.
Inherited Attributes
Inherited Attributes
An attribute
information item A, whether explicitly specified in the input
information set or defaulted as described in
, is potentially inherited by
an element information item E if and only if
A is among the attributes of one of E's ancestors.
A and E have the same
validation context.
A is an whose
= true.
A is not any
but A has a whose
= true.
If and only if an element information item P is not
(that is, it is either
strictly or
laxly assessed), in the post-schema-validation infoset each of
P's element information item childrenE which is not
a skip, has a
property:
A list of attribute information items. An attribute information item
A is included if and only if
A is by E.
Let O be A's owner element. A does not have the same expanded name
as another attribute which is also by E
and whose owner element is a descendant of O.
Constraints on Element Declaration Schema Components
All element declarations (see ) must satisfy the following
constraint.
Element Declaration Properties Correct
Element Declaration Properties Correct
For
any element declaration E,
The values of E's properties
.
are as described in the property tableau in
, modulo the
impact of .
If E has a non-absent,
then
E.
is a valid default with
respect to E.
as defined in .
If E. is
non-empty, then
E..
= global.
For each member M of E.,
E.
is for M.,
subject to the blocking keywords
in M..
There are no circular substitution groups.
That is, it is not possible to return to
E
by repeatedly following any member of the
property.
If E. exists,
then
for each in
E..,
the property is not absent.
If E. exists,
then for each T in
E.., and also for E...,
T is
for E., subject
to the blocking keywords of E..
T is the type
xs:error.
Element Default Valid (Immediate)
This and the following sections
define relations appealed to
elsewhere in this specification.
Element Default Valid (Immediate)
For aVto be a
valid default with respect to a type definition T
T is a simple type
definition or a complex type
definition with
. = simple
V is a valid default
with respect either
to T (if T is simple) or
(if T is complex) toT..
as defined by .
T is a complex type definition
with .
≠ simple
T.. = mixed.
The particle T..isemptiable
as defined by .
Substitution Group OK (Transitive)
Substitution Group OK (Transitive)
For an element declaration (call it M,
for member) to be
substitutable
for another element declaration (call it H,
for head)
at least
M and H are the same element
declaration.
H. does not contain
substitution.
There is a chain of
properties from
M to H, that is, either
M.containsH, or
M.contains a declaration whose
containsH, or . . .
The set of all
s involved in
the derivation of M. from
H. does not
intersect with the union of
(1)H.,(2)H..
(if H. is complex, otherwise
the empty set),
and
(3)
the
(respectively the empty set) of any intermediate
declared s
in the derivation of M. from
H..
Substitution Group
One element declaration is substitutable
for another if together they satisfy constraint .
Every element declaration (call this
HEAD) in the of a schema defines a substitution
group, a subset of those . An element declaration is in
the substitution group of HEAD if
and only if it is for
HEAD.
Complex Type Definitions
Complex Type Definitions provide for:
Constraining element information items by providing s governing the appearance and content of
attributes
Constraining element information item children to be empty,
or to conform to a specified element-only or mixed content model, or else
constraining the character information item children to conform to a
specified simple type definition.
Constraining
elements and attributes to exist,
not to exist, or to have specified values, with s.
Using the mechanisms of to derive a complex type from another simple or complex type.
Specifying post-schema-validation infoset contributions for elements.
Limiting the ability to derive additional types from a given complex type.
Controlling the permission to substitute, in an instance, elements of a derived
type for elements declared in a content model to be of a given complex type.
The XML representation of a complex type definition.
The Complex Type Definition Schema Component
A complex type definition schema component has the following
properties:
Complex type definitions are identified by their and . Except
for anonymous complex type definitions (those with no ), since
type definitions (i.e. both simple and complex type definitions taken together) must be uniquely identified within an XSD schema, no complex type definition can have the same name as another
simple or complex type definition. Complex type s and s
are provided for reference from
instances (see ), and for use in the XML
representation of schema components
(specifically in ). See for the use of component
identifiers when importing one schema into another.
The of a complex type is not ipso
facto the (local) name of the
element information items validated by that definition. The connection between a
name and a type definition is described in .
As described in , each complex type is derived from a
which is itself either a or a . specifies the means of derivation as either extension or restriction (see ).
A complex type with an empty specification for can be used as a
for other types derived by either of
extension or restriction; the explicit values extension, and restriction prevent further
derivations by extension and restriction respectively. If all values are specified, then the complex type is said to be
final, because no
further derivations are possible. Finality is not
inherited, that is, a type definition derived by restriction from a type
definition which is final for extension is not itself, in the absence of any
explicit final attribute of its own, final for anything.
The property is only relevant for anonymous type
definitions, for which its value is the component in which this type
definition appears as the value of a property, e.g.
.
Complex types for which is
truehave
no valid instances and thus cannot be used in the normal way as
the for the validation
of element information items (if for some reason an abstract
type is identified as the of an element
information item, the item will invariably be invalid). It
follows that such
abstract typesmust not be referenced from an
attribute in an instance document. Abstract
complex types can be used as s, or even as
the declared s of element declarations, provided in every
case a concrete derived type definition is used for validation, either via or the operation of a .
are a set of attribute uses. See
and for details of attribute validation.
s provide a more flexible specification for validation of
attributes not explicitly included in .
See , and
for formal
details of attribute wildcard validation.
determines the validation of children of element information items. Informally:
A with emptyvalidates elements
with no character or element information item children.
A with simplevalidates
elements with character-only childrenusing its .
A with element-onlyvalidates elements with children that
conform to the content model supplied by its .
A with mixedvalidates elements whose element children (i.e. specifically ignoring other children such as character information items)
conform to the content model supplied by its .
A with non-absentvalidates
elements with some children conforming to the
content modeland
others conforming to
the .
Not all combinations of and
are compatible with all properties of the . For example,
it is not allowed to derive a complex type with complex content
from a simple type.
The XML mapping rules specified in the following
section
(in particular of the rule for
the
in the rule for
of complex types with simple content, and
and
of the rule for
for complex types with complex content)
do not detect such incompatible combinations of properties;
in such cases the mapping rules will build a complex type
regardless of the fact that the properties specified are
incompatible. But the resulting complex type does
not satisfy component rules outlined in
or .
The property of a complex type definition T determines
whether type definitions derived from T are or are not
for T. Examples include (but are not limited
to) the substitution of another type definition:
as the of an element instance E,
when T is the of E
(often, the declared of E's
); this can occur when E specifies a type
definition using the xsi:type attribute;
see ;
as the of an element instance E,
when T is the declared of E's
; this can occur when conditional type
assignment is used;
see ;
as the of element instances
whose is included in a model group only
implicitly,
by virtue of being included in the
substitution group of
some element declaration present directlyindirectly
in the model group, whose declared is T.
as the of an
E1 where
E1 is contained in a D
D is derived from another B
B contains an E2 that has the same
expanded name as E1
E2 has T as its .
If is empty,
then all such substitutions are allowed;
if it contains the keyword restriction, then no type definition is
for T if its derivation from T involves
any restriction steps;
if contains
the keyword extension, then no type definition is
for T if its derivation from T involves
any extension steps.
In version 1.0 of this specification,
of a is only used when type substitution
(xsi:type) or element substitution (substitution groups) appear in
the instance document. It has been changed to take effect whenever complex type
derivation is checked, including cases beyond type and element substitutions in
instance documents. In particular, it affects
of ,
of ,
of ,
of ,
and of .
Because of the consideration of ,
existing schemas may be rendered invalid by the above rules. The XML Schema Working Group
solicits input from implementors and users of this specification as to whether
this change is desirable and acceptable.
constrain
elements and attributes
to exist, not to exist, or to
have specified values.
Though specified as a sequence, the order
among the assertions is not significant during assessment.
See .
See for information on the role of the
property.
XML Representation of Complex Type Definition Schema Components
The XML representation for a complex type definition schema component is a
element information item.
The XML representation for complex type definitions with a
with simple is significantly different from that
of those with other s, and this is reflected in the presentation below,
which describes
the mappings for the two cases in separate subsections.
Common mapping rules are factored out and given in
separate sections.
It is
a consequence of the concrete syntax given above that
a top-level
type definition need consist of no more than a name, i.e. that
<complexType name="anyThing"/> is allowed.
Aside from the simple coherence requirements outlined below, the requirement that type
definitions identified as restrictions actually be
restrictions — that is, the requirement that they accept
as valid only a subset of the items which are accepted as valid
by their base type definition — is enforced in .
The following sections describe
different sets of mapping rules for complex types; some
are common to all or many source declarations, others
only in specific circumstances.
If the source declaration
has a element as a child,
then it maps to a using the mapping
rules in
,
,
, and
.
If the source declaration
has a element as a child,
then it maps to a using the mapping
rules in
,
,
,
, and
.
If the source declaration
has neither a
nor a
element as a child,
then it maps to a using the mapping
rules in
,
,
,
, and
.
Where convenient, the mapping rules are
described exclusively in terms of the schema document's
information set. The mappings, however, depend not only upon
the source declaration but also upon the schema context. Some
mappings, that is, depend on the properties of other components
in the schema. In particular, several of the mapping rules
given in the following sections depend upon the having
been identified before they apply.
Common Mapping Rules for Complex Type Definitions
Whichever
alternative for the content of is
chosen, the following property mappings
apply.
Except where otherwise specified, attributes and child
elements are to be sought among the attributes and
children of the element.
The actual value of the
nameattribute if present, otherwise absent.The actual value of
the targetNamespaceattribute of the ancestor element information item if present,
otherwise absent.The actual value of the
abstractattribute, if present, otherwise
false.A set
corresponding to the actual value of the blockattribute, if present, otherwise to the actual value of the
blockDefaultattribute of the ancestor
element information item, if present,
otherwise on the empty string. Call this the
EBV (for effective block value). Then the
value of this property is
the EBV is the empty string
the empty set;
the EBV is #all
{extension,
restriction};
a set with members drawn from the set
above, each being present or absent depending on whether
the actual value (which is a list) contains an equivalently
named item.
Although the blockDefaultattribute of
may include values other than
restriction or extension, those values
are ignored in the determination of for complex type
definitions (they are used elsewhere).
As for above, but using the
final and finalDefaultattributes in place of the block and
blockDefaultattributes.If the nameattribute is
present, then , otherwise (the parent
element information item will be ), the corresponding to
that parent information item.
A sequence whose members are s drawn from the following sources, in order:
The
of the .
s corresponding to
all the element
information items among the children of , and , if
any, in document
order.
The of the set of
elements containing the , the child, if present,the children, if present, the and children, if present, and their and children, if present, and their andchildren, if present,
as defined in .
If the is a
complex type definition, then the always
contain members of the
of the , no matter which
alternatives are chosen in the XML representation,
or ,
or .
Mapping Rules for Complex Types with Simple Content
When the
source declaration has a
child, the
following elements are relevant
(as are ,
, and
),
and the
property
mappings are as below,
supplemented by the mappings in
,
,
and .
Note that either
or mustappear in
the content of .
When
the
element has a child, then
the
element maps to a complex type with
simple content, as follows.
The type
definition resolved to by the actual value of the
baseattributeon the
or
element appearing as a child of
If the
alternative
is chosen, then restriction, otherwise (the alternative is
chosen) extension.A as follows:simple
the
is a
complex type definition whose own has simple and the alternative
is chosen
starting from either
the simple type definition corresponding to the
among the children of
if there is one;
otherwise ( has no among its children), the
simple type definition which is the of the of
the
a simple type definition which restricts the
simple type definition identified in
or
with a set of facet components corresponding to the
appropriate element information items among the 's children (i.e. those
which specify facets, if any), as defined in ;
the
is a
complex type definition whose own has mixed and a which is
emptiable, as
defined in and the
alternative is chosen
(let SB
be the simple type definition corresponding to
the among the children of if any, otherwise
xs:anySimpleType) a simple type definition which
restricts SB with a set of facet
components corresponding to the appropriate element
information items among the 's children (i.e. those
which specify facets, if any), as defined in ;
If there is no among the children of
(and if therefore
SB is xs:anySimpleType), the result will be a simple type definition component
which fails to obey the constraints on simple type definitions, including
for example of
.
the
is a
complex type definition whose own
hassimple and the
alternative is chosen
the of the
of
that complex type definition;
the
is a
simple type definition and the
alternative is chosen
that simple type definition;
xs:anySimpleType.
Mapping Rules for Complex Types with Complex Content
When the
element does not have a child
element, then it maps to a complex type with complex
content. The
following elements are relevant (as are the
,,
and
elements,
which are described
more fully in
,
, and
, respectively, and which are
not repeated here), and the additional property
mappings are as below, supplemented
by the mappings in
,
,
,
, and
. Note that either
or mustappear in
the content of , but their
content
models are different in this case from the case above when they
occur as children of
.
Complex types with complex content can
be the image of two different forms of
element: one with a child (discussed in
), and one with neither
nor
as a child (discussed in
).
The mapping of the
is the same
in both cases; it is described in
.
Mapping Rules for Complex Types with Explicit Complex Content
When the
source declaration has a
child, the following mappings apply, supplemented by those
specified in
,
,
,
and
.
The type
definition resolved to by the actual value of the
baseattributeIf the
alternative is chosen, then restriction, otherwise
(the alternative is
chosen) extension.
Mapping Rules for Complex Types with Implicit Complex Content
When the source declaration
has neither nor
as a child, it is taken
as shorthand for complex content restricting
xs:anyType. The mapping rules specific to this
situation are as follows; the mapping rules for properties
not described here are as given in
,
,
,
and
.
xs:anyTyperestriction
Mapping Rules for Content Type Property of Complex Content
For complex types with complex content,
the property is
calculated as follows. (For the on complex types with simple content,
see .)
The mapping rule below refers here and there to elements
not necessarily present within a
source declaration. For purposes of evaluating tests like
If the abc attribute is present
on the xyz element, if no xyz
element information item is present, then no
abc attribute is present on the
(non-existent) xyz element.
When the mapping rule below refers to the
children, then for a
source declaration with a
child, then the children
of
or (whichever
appears as a child of ) are meant. If no is present, then the children of
the source
declaration itself are meant.
The mapping rule also refers to the value of the
property, whose value is determined as specified in
the preceding sections.
Let the effective mixed be
the mixedattribute is
present on
its actual value;
the mixedattribute is
present on
its actual value;
false.
It is a consequence of of
that
and
above will never contradict
each other in a conforming schema document.
Let the explicit content be
at least
There is no , , or among the
children;
There is an or among the children with no
children of its own excluding ;
There is among the
children a element
whose minOccursattribute
has the actual value0
and which has no
children of its own except for ;
The, , or element
among the
children has a maxOccursattribute with an actual value of 0;
empty
the particle corresponding to the
, ,
or
among the children.
Let the effective content be
the is empty
the effective
mixed is true
A particle whose properties are as
follows:
11
a model group whose is sequence and whose
is empty.
empty
the .
Let the explicit content type
be
= restriction
the effective
content is empty
a as follows:empty
a
as follows:mixed if
the effective
mixed is true, otherwise
element-onlyThe effective
content
= extension
the is a simple type
definition or is a complex type definition whose
. = empty or
simple
a as per
and above;
the is a complex type
definition whose . =
element-only or mixed and the
is empty
.;
a as
follows:mixedif
the effective
mixed is true, otherwiseelement-onlyLet the base particle be
the particle of the of the
. Then
the
of
the has
all and the
is empty
the .
the
of
the has
all and the of the
also has all
a whose properties are
as follows:
the
of the .
1
a model group whose is
all and whose are the of the
of the
followed
by the of the of the .
1
1
a model group whose is sequence
and whose are the followed by the
.
the of the
of the
.
Let the wildcard element be
the child is present
the child.
the child is not
present,
the
ancestor has a
child, and
the has ≠ empty
the has = empty and the element has
appliesToEmpty = true
the child of the
.
absent.
Then the value of the property is
the is absentor is present and has
mode = 'none'
the .
The of the
if it's not empty;
otherwise element-only.
The of the
if the of the
is not empty;
otherwise a
as follows:
11
a model group whose is sequence and whose
is empty.
An as follows:
The actual value of the modeattribute
of the , if present,
otherwise interleave.
Let W be the
wildcard corresponding to the child of the .If the
of the
is absent, then W; otherwise
a wildcard whose
and are those of W, and whose
is the
wildcard union of the
of W and
of . of
the , as defined in
.
It is a consequence of above that
when a type definition is extended, the same particles appear
in both the base type definition and the extension;
the particles are reused without being copied.
Mapping Rule for Attribute Uses Property
Any
source declaration can have and
elements as
children, or descendants. The
element is described in
and will not be repeated here.
The and
elements map to
the
property of the component
as described below. This mapping rule
is the same for all complex type definitions.
In the following rule, references to the
children refer to the children of
the
or
element (whichever
appears as a child of or
in the
source declaration),
if present, otherwise to the children of the
source declaration itself.
The rule also refers to the value of the
property, which is described elsewhere.
If the
ancestor has a
defaultAttributes attribute, and the element does not have
defaultAttributesApply =
false, then theproperty is
computed as if there were an
child with empty content
and a refattribute whose actual value is the
same as that of the
defaultAttributesattribute appearing after any other
children. Otherwise proceed as if there were no such
child.
Then the value is a union of sets of
attribute uses as follows
The set of attribute uses corresponding to the children, if any.
The of the
attribute groups resolved to by the actual values of the
refattribute of the children, if any.
The attribute uses inherited from the
T, as described by
T is a complex type definition and
= extension
the attribute
uses in T.
are inherited.
T is a
complex type definition and
= restriction
the attribute uses in
T. are
inherited, with the exception of those with an whose
expanded name is
the expanded name of the of an attribute use
which has already been included in the set, following
the rules in or above;
the expanded name of the of what would have
been an attribute use corresponding to an child, if the had not haduse =
prohibited.
This sub-clause handles the case where the
base type definition T allows the attribute
in question, but the restriction prohibits it.
no attribute use
is inherited.
The only substantive function of the value
prohibited for the use attribute of an
is in
establishing the correspondence between a complex type defined
by restriction and its XML representation. It serves to
prevent inheritance of an identically named attribute use from
the . Such an does not correspond to any component, and
hence there is no interaction with either explicit or
inherited wildcards in the operation of or .
It is pointless, though not an
error, for the use attribute to have the value
prohibited in other contexts (e.g. in complex type
extensions or named model group definitions), in which cases
the <attribute> element is simply ignored, provided that
it does not violate other constraints in this
specification.
Mapping Rule for Attribute Wildcard Property
The
property of a depends on the
element which may be present
within the element
or within the attribute groups referred to
within .
The
element is described in the preceding section
and will not be repeated here.
The following mapping rule
is the same for all complex type definitions.
References to the
children refer to the children of
the
or
element (whichever
appears as a child of or
in the
source declaration),
if present, otherwise to the children of the
source declaration itself.
The rule also refers to the value of the
property, which is described elsewhere.
If the ancestor has a
defaultAttributes attribute, and the
element does not have
defaultAttributesApply = false, then the
property is computed
as if there were an child with empty content and a refattribute
whose actual value is the same as that of the
defaultAttributesattribute appearing after any
other children. Otherwise proceed as if there were no such
child.
Let the complete wildcard be the
computed as described in
.
The value is then determined by
= restriction
the complete
wildcard;
= extension
let the base wildcard be
defined as
the
is a complex type definition with an
that .
absent.
The value is then determined by
the is
absent
the ;
the is
absent
the ;
a wildcard whose and
are those of the
, and whose
is the wildcard union of the
of the and of the , as
defined in .
Examples of Complex Type Definitions
Three ways to define a type for length
The following declaration defines a type for specifications of length
by creating a complex type with simple content, with
xs:nonNegativeInteger as the type of the
content, and a unit attribute to give the
unit of measurement.
A second approach to defining length
uses two elements, one for size and one for the unit of
measure. The definition of the type and the
declaration of the element might look like this:
A type definition for personal names, and a definition derived by
extension which adds a single element; an element declaration referencing the
derived definition, and a valid instance thereof.
A simplified type definition
derived from the base type from the previous example by restriction, eliminating
one optional child and
fixing another to occur exactly once; an element declared by reference to it,
and a valid instance thereof.
A complex type definition that
allows three explicitly declared child
elements, in the specified order (but not necessarily adjacent), and
furthermore allows additional elements of any name from any namespace other
than the target namespace to appear anywhere in the children.
To restrict away a local element declaration that competes with
a wildcard, use a wildcard in the derived type that explicitly
disallows the element's expanded name. For example:
<xs:complexType name="computer">
<xs:all>
<xs:element name="CPU" type="CPUType"/>
<xs:element name="memory" type="memoryType"/>
<xs:element name="monitor" type="monitorType"/>
<xs:element name="speaker" type="speakerType"
minOccurs="0"/>
<!-- Any additional information about the computer -->
<xs:any processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:all>
</xs:complexType>
<xs:complexType name="quietComputer">
<xs:complexContent>
<xs:restriction base="computer">
<xs:all>
<xs:element name="CPU" type="CPUType"/>
<xs:element name="memory" type="memoryType"/>
<xs:element name="monitor" type="monitorType"/>
<!-- Any additional information about the computer -->
<xs:any processContents="lax" notQName="speaker"
minOccurs="0" maxOccurs="unbounded"/>
</xs:all>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
The restriction type quietComputer has
a lax wildcard, which matches any element but one with the name
speaker.
Without the specification of the notQName attribute,
the wildcard would match elements named
speaker, as well. In that case, the restriction
would be valid only if there is a
top-level declaration for speaker that also has type
speakerType or a type derived from it.
Otherwise, there would be instances locally valid against the restriction
quietComputer that are not locally valid against the base type
computer.
For example, if there is no notQName attribute on the wildcard and
no top-level declaration for speaker, then the following is allowed
by quietComputer, but not by computer:
<speaker xsi:type="xs:string"/>
The specific rule violated in this case
is of
constraint
Constraints on XML Representations of Complex Type Definitions
Complex Type Definition Representation OK
In addition to the conditions imposed on element information items by the schema for schema documents,
If the alternative is chosen,
the
element must not
have mixed = true.
If is present
and has
mode ≠ 'none',
then there
must be an among the children of
.
If is present
and has mode = 'none',
then there must not be an among the children of
.
If the alternative is chosen and the
mixedattribute is present on both
and ,
then actual values of those attributesmust be the same.
Complex Type Definition Validation Rules
Locally Declared Type and Context-determined Type Table
This section defines the concepts of
and ;
these concepts play a role in determining whether restrictions
and extensions of complex type definitions are legitimate.
The
is also used to help determine the and
of an element information item.
Every determines a partial functional mapping from
element or attribute
information items (and their expanded names) to type
definitions. This mapping serves as a locally declared type
for elements
and attributes which are allowed by
the .
The attribute case is simpler and will be taken first.
For a given CTD and a given attribute
information item A, the
of
A within CTD is
CTD is xs:anyType
absent.
A has the same expanded name as some
attribute declaration D which is the
of some
contained by CTD's
the of D.
the
of A within
CTD..
The definition for elements is slightly
more complex.
For a given CTD and a given element information item E, the
of
E within CTD is
CTD is xs:anyType
absent.
Ehas the same expanded name as
some element declaration D which is contained by CTD's
content model, whether directly, indirectly, or implicitly
the
declared of D.
the
of
E within
CTD..
The constraint
ensures that even if there is more than one such declaration
D, there will be just one type definition.
The reference to implicit
containment ensures that if E has a
for a declaration
contained
by CTD's content model, a
is defined for E.
Similarly: Every
determines a partial functional mapping from element
information items (and their expanded names) to s.
The identified by this mapping is the context-determined
type table for elements which match a
contained by the content model of
the . For a given T and a given element information item E, the
of E in T is as follows:
T is xs:anyType
E has no in T.
Let D be an matched by E, given by
Ehas
the same expanded name as some element
declaration(s) contained by T's
content model, whether directly,
indirectly,
or implicitly
let D be any one of those s.
Ematches some strict or lax wildcard particle
contained by T's
content model, whether directly
or indirectly,
Ematches some top-level
let D be that top-level .
If E matches some as described above in
, then
the of E in T is given by
D has a
the of E in T is
the of D.
D has no
the of E in T is
the whose is the empty sequence
and whose is a whose
is absent and whose is
the declared of D.
If E matches no as described above in
, then
the of E in T
is the of E in T's .
The constraint
ensures that even if Ematches more than one such declaration
D, there will be just one .
It is a consequence of the definition of
that if any element E has a in any
complex type T, then E has a in any
complex type derived from T.
Element Locally Valid (Complex Type)
Element Locally Valid (Complex Type)
For an element information item E
to be locally valid with respect to a
complex type definition T
If E is not , then
T.. =empty
E has no character or element information item children.
T.. =simple
E has no element
information item children, and the initial value of E
is valid with respect
to T..
as defined
by .
T.. =element-only
E has no character information item children other
than those whose character code is defined as
a white space
in .
T.. =element-only or
T.. =mixed
the sequence of element
information items in
E.children, if any, taken in order,
is valid with
respect to T.,
as defined in
.
For each attribute information item A
in E.attributes
excepting those named xsi:type, xsi:nil,
xsi:schemaLocation, or xsi:noNamespaceSchemaLocation
(see ),
there is among the an
attribute use Uwhose
has the same expanded name as A
Aislocallyvalid
with respect to U
as per .
In this case U.
is the context-determined
declaration for A with respect
to and
.
Also A is
U.
There is an .
Aisvalid with respect
to it as defined in .
In this case A is
the .
For each attribute use U
in T.,
if U. = true,
then U.has the same
expanded name as
one of the attribute information items in
E.attributes.
It is a consequence that each such U will have
the matching attribute information item
it by
above.
For each A belonging to E,
the of
A's is valid with
respect to A..
as defined by
.
When an is
present, this does not introduce any ambiguity with
respect to how attribute information items for which an attribute use
is present amongst the whose name and target namespace match are
assessed. In such cases the attribute
use always takes precedence, and the of such items stands or falls
entirely on the basis of the attribute use and its . This follows from the details of
.
For each element information item in
E.children
and each attribute information item in
E.attributes, if
neither the
nor the
is absent, then
the is the same as, or is
for, the , without limitation.
E is valid
with respect to each of the assertions in
T. as
per .
Each element information
item in E.children,
together with
T,
satisfies .
A
defaulted attributebelonging to an element information item Egoverned by a complex type T
is any U
for which
U is a member of T..
U. = false.
U's is not absent.
U. is not one
of the s from .
U. does not match
any of the
attribute information items in E.attributes
as per of
above.
Element Sequence Locally Valid (Complex Content)
Element Sequence Locally Valid (Complex Content)
For a sequence S (possibly empty) of element information items
to be locally valid with respect to a
CT,
CT.
is absent
S is valid with respect
to CT., as defined in
.
CT.. = suffix
S can be represented as two subsequences S1 and
S2 (either can be empty) such that
S = S1 + S2
S1 is valid with respect
to CT., as defined
in .
If S2 is not empty, let E be the first element
in S2, then S1 + E does
not have a in
CT.
Every element in S2 is
valid with respect to the wildcard
CT.., as defined in
.
(CT.. = interleave) S
can be represented as two subsequences S1 and S2
(either can be empty) such that
S is a member of S1 × S2(where × is the interleave
operator, see )
S1 is valid with
respect to CT., as
defined in .
For every element E in S2, let S3 be
the longest
prefix of S1 where members of S3 are before
E in S, then S3 + E does
not have a in
CT.
Every element in S2 is
valid with respect to the wildcard
CT..,
as defined in
.
A sequence of element information items is locally valid with
respect to a if and only if it satisfies
with respect to that .
Attribution
During validation of an element
information item against its (complex) ,
associations
between element and attribute information items among the
children and attributes on the one hand, and the attribute uses,
attribute wildcard, particles
and open contentproperty record on the other, are
established. The element or attribute information item is
attributed to the corresponding component.
When an attribute information item
has the same expanded name as
the
of an
, then the item is attributed to that
attribute use. Otherwise, if the item matches an attribute wildcard, as
described in , then the item is
attributed to that wildcard. Otherwise the item is
notattributed to any component.
When a sequence S of child element information items are checked
against the 's CT, let S1 and S2 be subsequences of S
such that
S is a member of S1 × S2
S1 is a prefix of some element sequence that is
with respect to CT,
as defined in .
for every element E in S2, let S3 be
the longest
prefix of S1 where members of S3 are before
E in S, then S3 + E is
not a prefix of any element sequence that is
with respect to CT.
Then members of S1 that form a
in
CT. (see
) are attributed to
the particles they match up within the
. Other members of
S1 are attributed to the
of CT.
Members of S2 are notattributed to
any component.
The above definition
makes sure that
attribution happens even when the
sequence of element information items is not
with respect to a
. For example, if a complex type definition has the
following content model:
<xs:sequence>
<xs:element name="a"/>
<xs:element name="b"/>
<xs:element name="c"/>
</xs:sequence>
and an input sequence
<a/><b/><d/>
Then the element <a> is
attributed to the particle whose term is the
"a" element declaration. Similarly, <b> is attributed to the "b"
particle.
During validation, associations between
element and attribute information items among the children and
attributes on the one hand, and element and attribute declarations on
the other, are also established. When an item is attributed to an
, then it is associated with the declaration which is the
of the particle. Similarly, when an
attribute information item is an ,
then the item is associated with the
of that
. Such declarations are called the
context-determined declarations.
See (in )
for attribute declarations, (in
) for element declarations.
Conditional Type Substitutable
Conditional Type Substitutable
Given an element information item E and a complex type T,
let
B be the base type definition of T
TT be the of E in T, if any
TB be the of E in B, if any
ST be the conditionally selected for E
by TT, if TT exists
SB be the conditionally
selected for E by TB, if TB exists
E and T satisfy this constraint
if and only if
TB does not exist (i.e. E has no in B).
TT and TB both exist and at least
T has restriction,
and ST is for SB,
and E and B together satisfy this constraint.
T has extension,
and ST is identical to SB,
and E and B together satisfy this constraint.
This constraint has (by ) the effect of ensuring
that if T is a restriction of B, then any type
conditionally assigned to E in the context of T is a
restriction of the type which would be assigned to E in the
context of B.
It also ensures (by , together with
of the definition of
) that if any element declaration in a
complex type T has a , then the s
used for same-named elements in any types derived from T
will be consistent with that used in T.
The constraint above is
intended to ensure that the use of s for
conditional type assignment does not violate the usual principles of
complex type restriction.
More specifically, if T is a complex type definition derived from
its base type B by restriction, then the rule seeks to ensure that
a type definition conditionally assigned by T to some child element
is always derived by restriction from that assigned by B to the same child.
The current design enforces this using a "run-time" rule: instead of
marking T as invalid if it could possibly assign types incompatible
with those assigned by B, the run-time rule accepts the schema as valid
if the usual constraints on the declared s are satisified,
without checking the details of the s. Element instances are
then checked as part of validation, and any instances that would cause
T (or any type in T's base type definition chain) to assign the incompatible
types are made invalid with respect to T.
This rule may prove hard to understand or implement. The Working Group is
uncertain whether the current design has made the right trade-off and
whether we should use a simpler but more restrictive rule. We solicit
input from implementors and users of this specification as to whether
the current run-time rule should be retained.
Complex Type Definition Information Set Contributions
Attribute Default Value
Attribute Default Value
For each ,
the post-schema-validation infosethas an attribute information item whose
properties are as below added to the attributes of the element
information item.
In addition, if necessary
is performed on the element
information item for the 's
.
The 's .
The 's .
If the
has a non-absentN, then
a namespace prefix bound to N in the in-scope namespaces property
of the element information item in the post-schema-validation infoset.
If the
's
is absent, then
absent.
If
more than one
prefix is
bound to N in the in-scope namespaces, it is
implementation-dependent which of those prefixes is used.
The effective value constraint's .
The element information item being assessed.
The effective value constraint's .
The effective value constraint's
.
The effective value constraint's .
The nearest ancestor element information item with a
property.
valid.
full.
schema.
The added items
also
have
(and and
if appropriate) properties,
and
their lighter-weight alternatives, as specified in .
When
default values are supplied for attributes, namespace fixup
may be required, to ensure that the post-schema-validation infoset includes
the namespace bindings needed and maintains the consistency
of the namespace information in the infoset. To perform
namespace fixup on an element information item E for
a namespace N:
If the in-scope namespaces of Ebinds a prefix toN, no
namespace fixup is needed; the properties of E
are not changed.
Otherwise, first select some prefix P which is not bound by
the in-scope namespaces of E (the choice of
prefix
is implementation-dependent).
Add an entry to the in-scope namespaces of E binding P to N.
Add a namespace attribute to the namespace attributes of E.
Maintain the consistency of the information set by adjusting
the namespace bindings on the descendants of E. This may
be done in either of two ways:
Add the binding of P to N to the in-scope namespaces of all
descendants of E, except where that binding is overridden
by another binding for P.
Add to the namespace attributes of each child of E a namespace
attribute which undeclares the binding for P (i.e. a
namespace attribute for prefix P whose normalized value
is the empty string), unless that child already has a
namespace declaration for prefix P.
Note that this approach is possible
only if is in use,
rather than .
The choice between the two methods of maintaining
consistency in the information set is
implementation-dependent.
If the is occasioned by a defaulted attribute
with a non-absent target namespace, then (as noted above), the
prefix of the attribute information item supplied
in the post-schema-validation infoset is set to P.
When a default value of type QName
or NOTATION is applied,
it is implementation-dependent whether
occurs; if it does not, the prefix
used in the lexical representation (in
normalized value
or ) will
not necessarily map to the namespace name of the value
(in ).
To reduce problems and
confusion, users may prefer to ensure that the required namespace
information item is
present in the input infoset.
Match Information
Match Information
To allow users of the post-schema-validation infoset
to distinguish element information
items which are attributed to element particles from those
attributed to wildcard particles, if
and only if the
local validity of an element
information item has been assessed as defined by
,
then each attribute information item in its attributes
has the following properties in the post-schema-validation infoset:
the attribute information item is attributed to
an
an item isomorphic to
the .
the attribute information item is attributed to
an
an item isomorphic to
the attribute wildcard.
(the item is not attributed to
an or an
) absent.
A keyword indicating what kind of component the
attribute information item is attributed to.
the item is attributed to an
attribute
the item is attributed to a strict
strict
the item is attributed to a lax
lax
the item is attributed to a skip
skip
(the item is not attributed to
an or an
)
none
And each element information item in
its children has the following properties in the post-schema-validation infoset:
the element information item is attributed to
an or a
an item isomorphic to
the .
the item is attributed to an
an item isomorphic to
the .
(the item is not attributed to
a or an
) absent.
A keyword indicating what kind of the
item is attributed to.
the item is attributed to an
element
the item is attributed to a strict
strict
the item is attributed to a lax
lax
the item is attributed to a skip
skip
the item is attributed to an
open
(the item is not
attributed to a or
an ) none
Constraints on Complex Type Definition Schema Components
All complex type definitions (see ) must satisfy the following constraints.
Complex Type Definition Properties Correct
Complex Type Definition Properties Correct
The values of the properties of a complex type definition are as described in
the property tableau in
, modulo the impact of .
If the is a simple type
definition, the isextension.
There are no circular
definitions, except for that of xs:anyType. That is, it is
possible to reach the definition of
xs:anyType by repeatedly following the
.
No two distinct members of the
have
s
with the same expanded name.
If . is non-absent, then
. is either element-only
or mixed.
For every complex type T with
B where
T.
= extension,
B is a complex type definition
B.does not contain extension.
B.
is a subset of T..
That is, for every attribute use U in
B.,
there is an attribute use in
T.
whose properties, recursively, are identical to
those of U.
If B has an ,
thenTalso
has one, and B..
is a subset of
T.., as
defined by .
B and T both
have .
= simple and both have the same
..
B and T both have
.
=
empty.
T..
=
element-only or
mixed.
B.. = empty.
Both B and T have
.
= mixed or
both have .
= element-only.
T..
is a valid
extension of
B..,
as defined in .
B.. (call it BOT) is
absent.
T..
(call it EOT) has
interleave.
Both BOT and EOT
have
suffix.
If neither BOT nor
EOT is absent, then
BOT..
is a subset of
EOT.., as defined
by
.
It is in principle
possible to deriveT in two steps, the first
an extension and the second a restriction (possibly
vacuous), from that type definition among its ancestors
whose
is xs:anyType.
This requirement ensures that
nothing removed by a restriction is subsequently added
back by an extension in an incompatible way (for example,
with a conflicting type assignment or value
constraint).
Constructing the intermediate type definition to
check this constraint is straightforward: simply
re-order the derivation to put all the extension
steps first, then collapse them into a single
extension. If the resulting definition can be the
basis for a valid restriction to the desired
definition, the constraint is satisfied.
For any element or attribute information item, its
within T is
for the
within B, without limitation, if neither is absent.
B.
is a prefix of T..
B is a simple type definition
T..
= simple and
T.. =
B.
B.does not contain extension.
.
A complex type T is a valid extension of its
if and only if
T.
= extension
and
T
satisfies the constraint .
For every complex type T with
B where
T.
= restriction,
Bis a complex type definition whose
does not contain restriction.
Bisxs:anyType.
T..
= simple
Let SB be
B..,
and
ST be
T...
Then ST is validly derived from SB as defined
in
.
B.. = mixed and
B..
is a which is
emptiable as
defined in .
T..
= empty.
B..
= empty.
B.. =
element-only or
mixed, and
B..
is a
which is emptiable as defined in
.
T..
= element-only
and B..
= element-only or mixed.
T and B both have
.
=
mixed.
The of
Trestrictsthat of B as defined
in .
For every element information item E, if the attributes of E satisfy and
of
with respect to T, then they also satisfy the same
clauses with respect to
B,
and for every attribute information item A in E.attributes,
B's for Asubsumes that defined by
T.
For any element or
attribute information item, its
within T is
for its within
B, subject tothe blocking keywords
{extension, list, union}, if the item has a
both in
T and in B.
B. is a prefix of
T..
A complex
type definition with =restriction is a valid
restriction of its if and only if the constraint is
satisfied.
Valid
restriction involves both a subset relation on the set of
elements valid against T and those valid against B, and a derivation relation, explicit in the
type hierarchy, between the types assigned to attributes and
child elements by T and those assigned to the same
attributes and children by B.
The constraint just given,
like other constraints on schemas,
must be satisfied by every complex type T to which it
applies.
The above constraint allows a complex type with an
model groups to restrict another complex type with either
, , or
model groups. Even when the base type has an model
group, the list of member elements and wildcard may be very different
between the two types. The working group solicits feedback on how useful
this is in practice, and on the difficulty in implementing this feature.
However, under certain conditions conforming processors
need not (although they may) detect some violations of this constraint.
If (1) the type definition being checked
has T . . . .
= all
and (2) an implementation is unable to determine
by examination of the schema in isolation
whether or not
is satisfied, then the implementation may
provisionally accept the derivation.
If any instance encountered in the episode
is valid against T but not against T.,
then the derivation of T does not satisfy this
constraint, the schema does not conform to this
specification, and no can be performed
using that schema.
It is implementation-defined whether a processor (a) always
detects violations of
by examination of the schema in isolation, (b)
detects them only when some element information item
in the input document is valid against T but not
against T., or (c) sometimes detects
such violations by examination of the schema in isolation
and sometimes not. In the latter case, the circumstances
in which the processor does one or the other are
implementation-dependent.
This provision for validation-time checking of
this constraint on schemas is similar, in some ways,
to the validation-time checking of restrictions
involving conditional type assignment specified
in .
Both involve checking information items in the
instance being assessed against both a type and
its .
The two cases differ, however, in that a failure
to satisfy
makes the document instance invalid
( of
), while a failure to
satisfy the rule just given indicates an error
in the schema.
The above rule allows an implementation to use a potentially non-conforming
schema to perform schema assessment and produce PSVI. This results in
an exception of rules specified in .
The Working Group solicits input from implementors and users of this
specification as to whether this is an acceptable implementation
behavior.
Content Type Restricts (Complex Content)
Content type restricts (Complex Content)
A
R (for restriction)
with complex content (i.e. one with a non-absent)restricts another B (for
base) with complex content
if and only if
Every sequence of element information items which is
locally valid
with respect to R
is also locally valid
with respect to B.
For all sequences of element information items ES which are
locally valid
with respect to R, for all
elements E in ES,
B's for Esubsumes
that defined by R.
When a sequence of element information items ES
is locally valid
with respect to a
CTor when a set of attribute information items
AS satisfies and
of with respect to a ,
there is a (partial) functional mapping from
the element information items E in the sequence ESor the attribute information items in
AS
to a default binding for the item,
where the default binding is
an ,
an ,or one
of the keywords strict, lax, or skip,
as follows:
When the item has a , the
default binding is that .
When the item has a and it is attributed to an
, the default binding is
that .
When the item has a and it is attributed to an
attribute wildcard, the default binding is
an whose
is the ,
whose is absent, and
whose is the 's
(the other properties in the
are not relevant).
When the item is attributed to a strictor attribute wildcardor an
with a strict and
it does not have a or
a , then
the default binding is the keyword strict.
When the item is attributed to a laxor attribute wildcardor an
with a lax and
it does not have a or
a , then
the default binding is
the keyword lax.
When the item is attributed to a skipor attribute wildcardor an
with a skip then
the default binding is the keyword
skip.
A
G (for general) subsumes another
S (for specific) if and only if
G is skip.
G is lax
and S is not skip.
Both G and S are strict.
G and S are both Element Declarations and
Either
G. = true
or
S. = false.
Either G has no , or it is not fixed,
or S has a fixed with
an equal
value.
S.is
a superset of G..
S disallows a superset of the substitutions that G does.
S's declared is for G's declared .
G and S are both s and
G.. is
validly derived from
S..,
as
defined in .
Let GVC be G's
and SVC be S's
, then
GVC is absent or has
default.
SVC.
= fixed and
SVC. is
equal to
GVC..
G. =
S..
To restrict a complex type definition with a simple base type definition
to empty, use a simple type definition with a fixed value of
the empty string: this preserves the type information.
To restrict away a local element declaration that competes with
a wildcard, use a wildcard in the derived type that explicitly
disallows the element's expanded name. See the example given in
.
Type Derivation OK (Complex)
The following constraint defines a relation appealed to elsewhere
in this specification.
Type Derivation OK (Complex)
For a complex type definition (call it D, for
derived) to be validly derived from a type definition (call this
B, for base) subject tothe blocking keywords in
a subset of {extension,
restriction}
If B and D are not the same type
definition, then the of
Dis not
in the subset.
B = D.
B = D..
D.≠xs:anyType.
D. is complex
it is validly derived from Bsubject to the subset as defined by this constraint.
D. is simple
it is validly derived from Bsubject to the subset as defined in .
This constraint is used to check that when someone uses a type in a
context where another type was expected (either via xsi:type or
substitution groups), that the type used is actually derived from the expected
type, and that that derivation does not involve a form of derivation which was
ruled out by the expected type.
The wording of above appeals to a notion of component identity which
is only incompletely defined by this version of this specification.
In some cases, the wording of this specification does make clear the
rules for component identity. These cases include:
When they are both top-level components with the same component type,
namespace name, and local name;
When they are necessarily the same type definition (for example, when
the two type
definitions in question are the type definitions associated with
two attribute or element declarations, which are discovered to be the same
declaration);
When they are the same by construction (for example, when an element's
type definition defaults to being the same type definition as that of its
substitution-group head or when a complex type definition inherits an attribute
declaration from its base type definition).
In other cases
it is possible
that conforming implementations will
disagree as to whether components are identical.
When a complex type definition S is said to be
validly derived from a type definition T,
without mention of any specific set of blocking keywords,
or with the explicit phrase without limitation,
then what is meant is that S is validly derived from
T, subject to the empty set of blocking keywords,
i.e. without any particular limitations.
Built-in Complex Type Definition
There is a complex
type definition for xs:anyType present in every schema
by definition. It has the following properties:
Complex Type Definition of anyType
anyTypehttp://www.w3.org/2001/XMLSchemaitselfrestrictionA as follows:mixeda
with the properties shown
below in .The empty set
a wildcard with the following properties::
A with the following properties:anyThe empty setThe empty setlaxThe empty setThe empty setThe empty sequencefalse
The outer particle of xs:anyType contains a sequence with a single term:
Outer Particle for Content Type of anyType
11a model group with
the following properties:
sequence
a list containing one particle with the properties shown
below in .
The inner particle of xs:anyType contains a wildcard which matches any element:
Inner Particle for Content Type of anyType
0unboundeda wildcard with the following properties:
A with the following properties:anyThe empty setThe empty setlax
This specification does not provide an inventory of built-in complex
type definitions for use in user schemas. A preliminary library of complex type
definitions is available which includes both mathematical (e.g.
rational) and utility (e.g. array) type definitions.
In particular, there is a text type definition which is recommended for use
as the type definition in element declarations intended for general text
content, as it makes sensible provision for various aspects of
internationalization. For more details, see the schema document for the type
library at its namespace name: http://www.w3.org/2001/03/XMLSchema/TypeLibrary.xsd.
Attribute Uses
An attribute use is a utility component which controls the occurrence and
defaulting behavior of attribute declarations. It plays the same role for
attribute declarations in complex types that particles play for element declarations.
XML representations which all involve attribute uses, illustrating some of
the possibilities for controlling occurrence.
The Attribute Use Schema Component
The attribute use schema component has the following properties:
determines whether this use of an attribute
declaration requires an appropriate attribute information item to be present, or
merely allows it.
provides the attribute declaration itself,
which will in turn determine the simple type definition used.
allows for local
specification of a default or fixed value. This must be
consistent with that of the
, in that if
the specifies
a fixed value, the only allowed is the same fixed value, or a value equal to it.
See for information on the role of the
property.
XML Representation of Attribute Use Schema Components
Attribute uses correspond to all uses of which
allow a use attribute. These in turn correspond to
two components in each case, an attribute use and its (although note the latter is not new when the attribute use is a reference to a top-level attribute declaration). The appropriate mapping is described in .
Constraints on XML Representations of Attribute Uses
None as such.
Attribute Use Validation Rules
The effective value constraint of an attribute use
U
is U., if present, otherwise
U.., if present,
otherwise
the effective value constraint is absent.
Attribute Locally Valid (Use)
For an attribute information item to be valid with respect to an attribute use
its actual valuemustbe equal to the of the attribute use's , if it is present and has fixed.
Attribute Use Information Set Contributions
None as such.
Constraints on Attribute Use Schema Components
All attribute uses (see ) must satisfy the following constraints.
Attribute Use Correct
The values of the properties of an attribute use
Uare as
described in the property tableau in
, modulo
the impact of .
If U. is
not , then it is a valid default with
respect to
U..
as defined in .
If U. has
.
= fixed and U itself has a
, then
U..
= fixed and
U..
is identical to
U....
Attribute Group Definitions
A schema can name a group of attribute declarations so that they can be incorporated as a
group into complex type definitions.
Attribute group definitions do not participate in validation as such, but the
and
of one or
more complex type definitions may be constructed in whole or part by reference
to an attribute group. Thus, attribute group definitions provide a
replacement for some uses of XML's
parameter entity facility.
Attribute group definitions are provided primarily for reference from the XML
representation of schema components
(see and ).
XML representations for attribute group definitions. The effect is as if the attribute
declarations in the group were present in the type definition.
The example above illustrates the pattern
mentioned in : The same
element, in this case attributeGroup, serves both to
define and to incorporate by reference. In the first
attributeGroup element in the example, the
name attribute is required and the
ref attribute is forbidden; in the second the
ref attribute is required, the
name attribute is forbidden.
The Attribute Group Definition Schema Component
The attribute group definition schema component has the
following properties:
Attribute groups are identified by their and ; attribute group identities must be unique within an XSD schema. See for the use of component
identifiers when importing one schema into another.
is
a set of
attribute uses, allowing
for local specification of occurrence and default or fixed values.
provides for an attribute wildcard to be included in an
attribute group.
See above under for the
interpretation of
attribute wildcards during validation.
See for information on the role of the
property.
XML Representation of Attribute Group Definition Schema Components
XML Mapping Rule for Named Attribute Groups
The XML representation for an attribute group definition
schema component is an element information item. It provides for naming a group of
attribute declarations and an attribute wildcard for use by
reference in the XML representation of complex type definitions
and other attribute group definitions. The correspondences between the
properties of the information item and properties of the
component it corresponds to are given in this section.
When an appears as a child of
or , it corresponds to an
attribute group definition as below. When it appears as a
child of or , it does
not correspond to any component as such.
The actual value of the nameattributeThe actual value of the
targetNamespaceattribute of the
ancestor
element information item if present, otherwise absent.
The union of the set of attribute uses corresponding to the
children, if any, with the
of the attribute groups
resolved to by the actual values of the refattribute of the children, if any.
As described below, circular references from
to are not errors.
The determined by
applying the attribute-wildcard mapping described
in
to the
element information item.
The of the
element and
its children, if present,
as defined in .
It is a consequence of this rule and the rule in
that any annotations specified in attribute group references are included in
the sequence of s of the enclosing or
components.
The rules given above for
and specify that
if an element A contains a reference
to another attribute group B (i.e. A's children include an
with a ref attribute pointing
at B), then A maps to an component whose
reflect not only
the children of A but also those of
B and of any elements referred
to in B. The same is true for attribute groups referred to from
complex types.
Circular reference is not disallowed. That is, it
is not an error if B, or some
element referred to by B (directly, or indirectly at some
remove) contains a reference to A. An
element involved in such a reference cycle maps to a
component whose
and properties
reflect all the and
elements contained in, or referred to (directly or indirectly)
by elements in the cycle.
In version 1.0 of this specification, circular group reference was not
allowed except in the children of .
As described above, this version allows it.
The effect is to take the transitive closure of the
reference relation between
elements and take into account
all their and
properties.
Common Rules for Attribute Wildcards
The following mapping for attribute-wildcards forms part of the
XML mapping rules for different kinds of source declaration
(most prominently ). It can be
applied to any element which can have an
element as a child, and produces as a result either a
or the special value absent.
The mapping depends on the concept of the :
Thelocal wildcardof
an element information item Eis
E has
an child
the
mapped to by the element using the wildcard
mapping set out in
;
absent.
The mapping is defined as follows:
Let L be the
Let W be a sequence containing all the non-absents
of the attribute groups referenced
by E, in document order.
The value is then determined by
W is empty
the local
wildcardL.
L is non-absent
a wildcard whose
properties are as follows:L.L.the
wildcard intersection
of L. and of the
s of all
the the wildcards in W,
as defined in
(no is
present)
a wildcard whose properties are as follows:
The of the first
wildcard in W
The wildcard intersection
of the s
of all the wildcards in W,
as defined in The empty sequence
Constraints on XML Representations of Attribute Group Definitions
Attribute Group Definition Representation OK
None as such.
Attribute Group Definition Validation Rules
None as such.
Attribute Group Definition Information Set
Contributions
None as such.
Constraints on Attribute Group Definition Schema Components
All attribute group definitions (see ) must satisfy the following constraint.
Attribute Group Definition Properties Correct
The values of the properties of an attribute group definition
are as described in the property tableau in
, modulo the impact
of ;
No two
distinct members of the have
s with the same
expanded name.
Model Group Definitions
A model group definition associates a name and optional annotations with
a .
By reference to the name, the entire model group can be incorporated by reference into
a .
Model group definitions are provided
primarily for reference from the (see
and ). Thus, model group definitions provide a
replacement for some uses of XML's
parameter entity facility.
A minimal model group is defined and used by reference, first as the whole
content model, then as one alternative in a choice.
The Model Group Definition Schema Component
The model group definition schema component has the following
properties:
Model group definitions are identified by their and ; model group identities must be unique within an XSD schema. See for the use of component
identifiers when importing one schema into another.
Model group definitions per se do not participate in validation, but the of
a particle may correspond in whole or in part
to a model group from a model group definition.
is the for which the model group definition provides a name.
See for information on the role of the
property.
XML Representation of Model Group Definition Schema Components
The XML representation for a model group definition schema component is a
element information item.
It provides for
naming a model group for use by reference in the XML representation of
complex type definitions and model groups. The correspondences between the
properties of the information item and
properties of the component it corresponds to are given in this section.
If there is a
nameattribute (in which case the item will
have or as parent), then the item maps
to a model group definition component with properties as
follows:
The actual value of the
nameattributeThe actual value of
the targetNamespaceattribute of the
ancestor element information
item if present, otherwise absent.A model group which is
the of a particle
corresponding to the , or
among the children (there must
be exactly one). The of the
element, as defined in .
Otherwise,
if
the item
has
a refattribute
and does not have minOccurs=maxOccurs=0, then
the element maps
to a particle component with properties
as follows:
The actual value of the
minOccursattribute, if present, otherwise
1.unbounded, if the
maxOccursattribute equals
unbounded, otherwise the actual value of the
maxOccursattribute, if present, otherwise
1.The of the model group definition
resolved to by the actual value of the refattribute
The of the
element, as defined in .
Otherwise, the
has minOccurs=maxOccurs=0, in which
case it maps to no component at all.
The name of this section is slightly misleading, in that the
second, un-named, case above (with a ref and no
name) is not really a named model group at all, but
a reference to one. Also note that in the first (named) case
above no reference is made to minOccurs or
maxOccurs: this is because the schema for schema documents does not
allow them on the child of when it is
named. This in
turn is because the and
of the particles which
refer to the definition are what count.
Constraints on XML Representations of Model Group Definitions
None as such.
Model Group Definition Validation Rules
None as such.
Model Group Definition Information Set Contributions
None as such.
Constraints on Model Group Definition Schema Components
All model group definitions (see ) must satisfy the following constraint.
Model Group Definition Properties Correct
The values of the properties of a model group definition must be as described in
the property tableau in
, modulo the impact of .
Model Groups
When the children of element information items are not constrained
to be empty or by reference to a simple type definition
(), the sequence of element
information item children content may be specified in
more detail with a model group. Because the
property of a particle can be a
model group, and model groups contain particles, model groups can indirectly
contain other model groups; the grammar for model groups
is therefore recursive.A model group
directly contains the particles in the value of its
property.A model group
indirectly contains the particles, groups, wildcards, and
element declarations which are contained
by the particles it
.A model group
contains the components which it either
or .
XML representations for the three kinds of model group, the third nested
inside the second.
The Model Group Schema Component
The model group schema component has the following
properties:
specifies a sequential (sequence),
disjunctive (choice) or conjunctive (all) interpretation of
the . This in turn
determines whether the element
information item childrenvalidated by the model group must:
(sequence) correspond, in order, to the specified ;
(choice) correspond
to exactly one of the specified ;
(all) correspond to the specified . The elements can occur in any
order.
When two or more
element declarations contained
directly,
indirectly, or
implicitly in the
of a model group have identical names, the type definitions of those declarations must be the
same.
See for information on the role of the
property.
XML Representation of Model Group Schema Components
The XML representation for a model group schema component is
either an
, a or a
element information item. The correspondences between the
properties of those information items and
properties of the component they correspond to are given in this section.
Each of the
above items corresponds to a particle containing a model group,
with properties as follows (unless minOccurs=maxOccurs=0,
in which case the item corresponds to no component at all):
The actual value of the minOccursattribute, if present, otherwise 1.unbounded, if the maxOccursattribute equals unbounded, otherwise the actual value of the maxOccursattribute, if present, otherwise 1.A model group as given below.
The same annotations as the of
the model group. See below.
The particle just described has a
as the value of its property, as follows.
One of all,
choice, sequence depending on the element
information item.A sequence of particles
corresponding to all the , ,
, ,
or items among
the children, in order. The of the
, , or element, whichever is present, as defined
in .
Constraints on XML Representations of Model Groups
None as such.
Model Group Validation Rules
In order to define the validation rules for model
groups clearly, it will be useful to define some basic terminology;
this is done in the next two sections, before the validation rules
themselves are formulated.
Language Recognition by Groups
Each model group M denotes a language
L(M), whose members are the sequences of element information items
accepted by M.
Within L(M) a smaller language V(M) can be
identified, which is of particular importance for schema-validity
assessment. The difference between the two languages is that
V(M) enforces some constraints which are ignored in the definition
of L(M).
Informally L(M) is the set of sequences which are accepted by a model
group if no account is taken of the schema component
constraint or the related provisions
in the validation rules which specify how to choose a unique
in a non-deterministic model group. By contrast, V(M) takes
account of those constraints and includes only the sequences which are
against M. For all model groups M, V(M) is a
subset of L(M). L(M) and related concepts are described in this
section; V(M) is described in the next section, .
When a sequence S of element information
items is checked against a model group M, the sequence of
basic particles
which the items of S match, in order, is a
path of S in M. For a given S and
M, the
path of S in
M is not necessarily unique.
Detailed rules for the matching, and thus for the construction of
paths, are given in and .
Not every sequence has a path in every model group, but every
sequence accepted by the model group does have a path.
For
a model groupM and a sequence S in L(M), the path
of S in M is a complete path; prefixes of
complete paths which are themselves not complete paths
are incomplete paths.
For example, in the model group
the sequences (<a/><b/><c/>)
and (<a/><b/>) have paths
(the first a and the second
an incomplete path),
but the sequences (<a/><b/><c/><d/>) and
(<a/><x/>) do not
have paths.
It is possible, but unusual, for a model group to
have some paths which are neither complete paths, nor
prefixes of complete paths. For example, the model group <xs:sequence>
<xs:element name="a"/>
<xs:element name="b"/>
<xs:choice/>
</xs:sequence>
accepts no sequences because the empty choice recognizes
no input sequences. But the sequences (<a/>)
and (<a/><b/>) have paths in the model group.
The definitions of L(M) and paths in M, when M is a or
a , are given in
. The definitions for groups are
given below.
Sequences
This section defines L(M), the set of
paths in M, and V(M), if M
is a sequence group.
If M is a ,
and the of M is sequence,
and the of M is the sequence P1, P2, ...,
Pn, then L(M) is the set of sequences S = S1 + S2 + ... +
Sn (taking + as the concatenation operator), where
Si is in L(Pi) for 0 < i ≤ n.
The sequence of sequences S1, S2, ..., Sn is a of
S.
Less formally, when M is a sequence of P1, P2, ... Pn, then
L(M) is the set of sequences formed by taking one sequence which is
accepted by P1, then one accepted by P2, and so on, up through
Pn, and then concatenating them together in order.
A
partition of a sequence is a sequence of sub-sequences,
some or all of which may be empty, such that concatenating all
the sub-sequences yields the original sequence.
When M is a sequence group
and S is a sequence of input items, the set of paths of S
in M is the set of all
paths Q = Q1 + Q2 + ... + Qj, where
j ≤ n, and
S = S1 + S2 + ... + Sj (i.e. S1, S2, ..., Sj is
a of S), and
Si is in L(Pi) for 0 < i < j, and
Qi is a of Si in Pi for 0 < i ≤ j.
By this definition, some sequences which do not satisfy the
entire model group nevertheless have paths in a model group.
For example, given the model groupM
where n = 3, j = 2, then
S1 is (<a/>),
S2 is (<b/>),
and
S has a in M, even though S is not in
L(M). The has two items, first the
for the a element, then the for the
b element.
When M is a sequence group,
the set V(M) (the set of sequences
against M) is the set of sequences S which
are in L(M) and which have a in M.
Informally, V(M) contains those sequences which are
accepted by M and for which no element information item
is ever a if it can, in
context, instead be an .
There will invariably be a of S whose
members are against
of M.
For sequences with more than one in M,
the attributions of
the are used in validation and for determining
the contents of the post-schema-validation infoset. For example, if M is
<xs:sequence>
<xs:any minOccurs="0"/>
<xs:element name="a" minOccurs="0"/>
</xs:sequence>
then the sequence (<a/>) has two paths
in M, one containing just the and the other
containing just the . It is the latter
which is a and which determines which
the item in the input is .
There are model groups for which some members of
L(M) are not in V(M). For example, if M is
<xs:sequence>
<xs:any minOccurs="0"/>
<xs:element name="a"/>
</xs:sequence>
then the sequence (<a/><a/>) is in L(M), but not
in V(M), because the validation rules require that the first
a be the .
In a the initial a will invariably be
the , and so no sequence
with an initial a can be against
this model group.
Choices
This section defines L(M), the set of
paths in M, and V(M), if M
is a choice group.
When the of M is choice, and the of M is the sequence P1, P2, ..., Pn,
then
L(M) is
L(P1) ∪ L(P2) ∪ ... ∪ L(Pn),
and the set of paths of S in P is the set
Q = Q1 ∪ Q2 ∪ ... ∪ Qn, where
Qi is the set of paths of S in Pi, for
0 < i ≤ n.
Less formally, when M is a choice of P1, P2, ... Pn, then
L(M) contains any sequence accepted by any of the particles P1, P2, ... Pn,
and any of S in any of the particles P1, P2, ... Pn
is a of S in P.
The set V(M) (the set of sequences
against M) is the set of sequences S which
are in L(M) and which have a in M.
In effect, this means that if one of the choices in Mattributes an initial element information item to
a , and another attributes the same
item to an , then the latter choice is used
for validation.
For example, if M is
<xs:choice>
<xs:any/>
<xs:element name="a"/>
</xs:choice>
then the for the sequence (<a/>)
contains just the and it is to the
that the input element will be
attributed; the alternate
containing just the is not relevant for
validation as defined in this specification.
All-groups
This section defines L(M), the set of
paths in M, and V(M), if M
is an all-group.
When the of M is all, and the of M is the sequence P1, P2, ..., Pn,
then
L(M) is the set of sequences
S = S1 × S2 × ... × Sn
(taking × as the interleave operator),
where
for 0 < i ≤ n, Si is in L(Pi).
The set of sequences
{S1, S2, ..., Sn} is a of S.
The set of paths of S in P is
the set of all pathsQ = Q1 × Q2 × ... × Qn,
where Qi is a of Si in Pi,
for 0 < i ≤ n.
Less formally, when M is an all-group of P1, P2, ... Pn, then
L(M) is the set of sequences formed by taking one sequence which
is accepted by P1,
then one accepted by P2,
and so on, up through Pn, and then interleaving them
together. Equivalently, L(M) is the set of sequences S
such that the set {S1, S2, ..., Sn} is a
of S, and
for 0 < i ≤ n, Si is in L(Pi).
A
grouping of a sequence is a set of sub-sequences, some or
all of which may be empty, such that each member of the original
sequence appears once and only once in one of the sub-sequences and
all members of all sub-sequences are in the original
sequence.
For example, given the model groupM <xs:all>
<xs:element name="a" minOccurs="0" maxOccurs="5">
<xs:element name="b" minOccurs="1" maxOccurs="1">
<xs:element name="c" minOccurs="0" maxOccurs="5">
</xs:element>
</xs:all>
and an input sequence S<a/><b/><a/>
where n = 3, then
S1 is (<a/><a/>),
S2 is (<b/>),
and the of
S in M is the sequence containing first the
for the a element, then the for the
b element, then once more the
for the a element.
The set V(M) (the set of sequences
against M) is the set of sequences S which
are in L(M) and which have a in M.
In effect, this means that if one of the in Mattributes an element information item to
a , and a competingattributes the same item to an , then the
is used for validation.
For example, if M is
<xs:all>
<xs:any/>
<xs:element name="a"/>
</xs:all>
then M accepts sequences of length two, containing
one a element and one other element.
The other element can be anything at all, including a second
a element. After the first a
the accepts no more elements
and so no longer competes with the .
So if the sequence (<a/><a/>)
is checked against M, in the the
first a element will be
the and the second to the
.
If the intention is not to allow the second a,
use a wildcard that explicitly disallows it. That is,
<xs:all>
<xs:any notQName="a"/>
<xs:element name="a"/>
</xs:all>
Now the sequence (<a/><a/>) is not
accepted by the particle.
Multiple Paths in Groups
It is possible for a given sequence of element information items
to have multiple paths in a given model group M; this is
the case, for example, when M is ambiguous, as for example
which can match the sequence (<a/><b/>)
in more than one way.
It may also be the case with unambiguous model groups, if
they do not correspond to a deterministic
expression (as it is termed in )
or a 1-unambiguous expression, as it
is defined by .
For example,
Because these model groups do not obey the
constraint , they cannot
appear in a conforming schema.
Principles of Validation against Groups
As noted above, each model group M denotes a
language L(M), whose members are sequences of element information
items. Each member of L(M) has one or more paths in M, as do
other sequences of element information items.
By imposing conditions on paths in a model group M
it is possible to identify a set of validation-paths in M,
such that if M is a
model group which obeys the
constraint, then
any sequence S has at most one in M.
The language V(M) can then be defined as the set of
sequences which have validation-paths in M.
Two
P1 and P2 contained in some Pcompete with each other if and only if some sequence S
of element information items has two paths in P which are
identical except that one path has P1 as its last item and the other
has P2.
the sequence (<a/><b/>) has two paths,
one (Q1) consisting of the whose is
the declaration for a followed by the
whose is
the declaration for b, and
a second (Q2) consisting of the whose is
the declaration for a followed by the
whose is
the wildcard. The sequences Q1 and Q2 are
identical except for their last items, and so the
two which are the last items of Q1 and
Q2 are said to with each other.
By contrast, in the content model
<xs:choice>
<xs:sequence>
<xs:element name="a"/>
<xs:element name="b"/>
</xs:sequence>
<xs:sequence>
<xs:element name="c"/>
<xs:any/>
</xs:sequence>
</xs:choice>
the for b and the
wildcard do not , because there is no
pair of paths in P which differ only in one
having the for b and
the other having the .
Two
(or more) paths of a sequence S in a P
are competing paths if and only if
they are identical except for their final items, which
differ.
For any sequence S of element
information items and any particle P, a of S in P
is a validation-path if and only if for each
prefix of the which ends with a , the
corresponding prefix of S has no competing path which
ends with an .
It is a consequence of the definition of that for
any content model M which obeys constraint
and for any sequence S of
element information items, S has at most one
in M.
A sequence S of
element information items is locally valid against
a particle P if and only if
S has a in P. The set of all such
sequences is written V(P).
Element Sequence Valid
Element Sequence Valid
For a sequence S (possibly empty) of element information items to be
locally valid with respect to
a model group M, Smust be in V(M).
It is possible to define groups whose
is empty. When a choice-group M has an empty
property, then
L(M) is the empty set.
When M is a sequence- or all-group with an empty
property, then
L(M) is the set containing the empty (zero-length) sequence.
Model Group Information Set Contributions
None as such.
Constraints on Model Group Schema Components
All model groups (see ) must satisfy the following constraints.
Model Group Correct
Model Group Correct
The values of the properties of a model group are as
described in the property tableau in
, modulo the impact of .
There are no circular
groups. That is, within the
of a group there
is no
particle at any depth whose
is the group itself.
All Group Limited
All Group Limited
When a model group has all, then
It appears only as the value of one or more of the following properties:
the property of a model group definition.
the property of a with
= 1 which is
the
of the of a complex
type definition.
the property of a P with
== 1, where
P is among the of a
whose is
all.
For every particle P in its ,
if P. is a model group,
then P..
= all.
Element Declarations Consistent
Element Declarations Consistent
If the property contains, either
directly, indirectly (that is, within the property of a
contained model group, recursively),
or implicitly, two or more
element
declarations with the same expanded name, then all their type
definitions must be the same top-level definition, that is,
All
their declared s have a non-absent.
All
their
declared s have the same
.
All
their
declared s have the same
.
All their s are either
all absent or else all are present and
have the same sequence of and
the same .
If
The property contains (either directly,
indirectly, or implicitly) one or more
element declarations with the same expanded nameQ; call these element
declarations EDS.
At least
The property contains one or more
strict or laxwildcard particles which matchQ.
The is the of the
of some CTD and
CTD. has an
with a strict or lax which
matchesQ.
There exists a top-level element declaration G with the expanded nameQ.
then the s of EDS
and the of
Gmust either
all be absent or else all be present and
have the same sequence of and
the same .
A list
of particles implicitly contains an element declaration if and only if a
member of the list contains that
element declaration in its substitution group.
Unique Particle Attribution
An element particle is a whose is an .
A wildcard particle is a whose is a .
Wildcard particles may be
referred to as strict, lax,
or skip particles,
depending on the
property
of their .
Unique Particle Attribution
A content model must not contain two
element particles which with each other, nor two
wildcard particles which with each other.
Content models in which an and a with each other are not prohibited.
In such cases, the is chosen;
see the definitions of
attribution
and .
This constraint reconstructs for XSD the equivalent
constraints of and SGML. See for further
discussion.
Since this constraint is expressed at the component level, it
applies to content models whose origins (e.g. via type derivation and
references to named model groups) are no longer evident. So particles at
different points in the content model are always distinct from one another,
even if they originated from the same named model group.
It is a consequence of , together with
the definition of , that any sequence S of element
information items has at most one in any particle P.
This means in turn that each item in S is attributed to at most one particle in P.
No item can match more than one
or more than one (because no two wildcard particles
and no two element particlesmay), and if an item matches
both a and an , it is attributed by
the rules for validation-paths to the .
Because locally-scoped element declarations sometimes
have and sometimes do not have a
, the scope of
declarations is not relevant to enforcing either
the
constraint or the
constraint.
Effective Total Range (all and sequence)
The following constraints define relations appealed to elsewhere in this specification.
Effective Total Range (all and sequence)
The effective total range of a particle P
whose is a group G
whose is
all or sequence is a pair of minimum and maximum, as follows:
The product of P. and the
sum of the of every wildcard or element
declaration particle in G. and the minimum
part of the effective total range of each of the group particles in
G. (or 0
if there are no
).
unbounded if the of any wildcard or element
declaration particle in G. or the maximum
part of the effective total range of any of the group particles in
G. is unbounded,
or if any of those is non-zero
and P.
= unbounded,
otherwise the product of P. and the
sum of the of every wildcard or element
declaration particle in G. and the maximum
part of the effective total range of each of the group particles in
G.
(or 0 if there are no
).
Effective Total Range (choice)
Effective Total Range (choice)
The effective total range of a particle P
whose is a group G
whose is
choice is a pair of minimum and maximum, as follows:
The product of P. and the
minimum of the of every wildcard or element
declaration particle in G. and
the minimum part of the effective total range of each of the group particles
in G.
(or 0 if there are no ).
unbounded if the of any wildcard or element
declaration particle in G. or the maximum
part of the effective total range of any of the group particles in
G. is unbounded,
or if any of those is non-zero and
P. = unbounded,
otherwise the product of P. and the
maximum of the of every wildcard or element
declaration particle in G. and the maximum
part of the effective total range of each of the group particles in
G.
(or 0 if there are no ).
Particles
As described in , particles contribute
to the definition
of content models.
When an element is validated against a complex type,
its sequence of child elements is checked against the content model of
the complex type and the children are to of the content model.
The attribution of items to
determines the calculation of the items'
context-determined
declarations
and thus partially determines the governing
element declarations for the children:
when
an element information item is an
, that 's ,
or an for it,
becomes
the item's context-determined
declaration and
thus normally its ; when the item is a
, the
depends on the property of the wildcard and
on .
XML representations which all involve particles, illustrating some of
the possibilities for controlling occurrence.
The Particle Schema Component
The particle schema component has the following properties:
In general, multiple element
information item children, possibly with intervening character children if the content type
is mixed, can be validated with
respect to a single particle. When the is an element
declaration or wildcard, determines the minimum number of such element children that can occur. The number of such children must be greater than or equal to . If is 0, then occurrence of such children is optional.
Again, when the is an element
declaration or wildcard, the number of such element childrenmust be less than or equal to any numeric specification of
; if is unbounded, then there is no
upper bound on the number of such children.
When the is a model group, the permitted
occurrence range is determined by a combination of and and the occurrence ranges of the 's .
A particle
directly contains the component which is the value of its
property.A particle
indirectly contains the particles, groups, wildcards, and
element declarations which are contained by the value of its
property.A particle
contains the components which it either
or .
See for information on the role of the
property.
XML Representation of Particle Schema Components
Particles correspond to all three elements ( not immediately within
, not immediately within and ) which allow
minOccurs and maxOccurs attributes.
These in turn correspond to two components in each
case, a particle and its
. The appropriate mapping is
described in , and respectively.
Constraints on XML Representations of Particles
None as such.
Particle Validation Rules
Principles of Validation against Particles
Every particle Precognizes some language L(P).
When and of P are
both 1, L(P) is the language of P's ,
as described in . The
following section ()
describes how more complicated counts are handled.
Language Recognition for Repetitions
When P. = P. = n,
and P. = T,
then L(P) is the set of sequences S = S1 + S2 + ... + Snsuch that Si is in L(T) for 0 < i ≤ n.Less formally: L(P) is
the
set of sequences which have partitions into n sub-sequences
for which each of the n subsequences
is in the language accepted by the of P.
When P. = j
and P. = k,
and P. = T,
then L(P) is the set of sequences S = S1, + S2 + ... + Sn, i.e. the
set of sequences which have partitions into n sub-sequences
such that n ≥ j and n ≤ k (or k is unbounded)
and Si is in L(T) for 0 < i ≤ n.
When P. = 0,
then L(P) also includes the empty sequence.
If (1) P has
= j, = k, and = T,
and (2) S is a sequence of element information items
such that S = S1 + S2 + ... + Sn (i.e. S1, S2, ..., Sn is
a of S),
and (3) n ≤ k (or k is unbounded),
and (4) Si is in L(T) for 0 < i < n,
then:
If T is a model group,
then the set of paths of S in P is the set of all pathsQ such that
Q = Q1 + Q2 + ... + Qn, where
Qi is a of Si in T for 0 < i ≤ n.
(For the definition of paths in model groups,
see .)
If T is a , then the (sole) of S in P
is a sequence of n occurrences of P.
Informally: the path of an input sequence S in a
particle P may go through the basic particles in
P as many times as is allowed by
P..
If the path goes through P more than once, each
time before the last one must correspond to a sequence
accepted by
P.;
because the last
iteration in the path
may not be complete, it need not be accepted by the
.
Validation of Basic Terms
In the preceding section (), the language L(P) accepted by a
P is defined in terms of the language accepted by P's
. This section defines L(T) for basic terms;
for the definition of L(T) when T is a group,
see .
For any D, the language
L(D)accepted by D
is the set of all sequences of
length 1 whose sole member is an element information item which
matchesD.
An element information item Ematches an D if and only if
E and D have the same expanded name,
The expanded name of Eresolves to an element
declaration D2 which is
for D.
An
expanded nameEmatches an
NCNameN and
a namespace name NS(or, equivalently, N and NSmatchE)
if and only if all of the following
are true:
The local name of E is identical to N.
Either the namespace name of E is identical to NS,
or else E has no namespace name (E is an unqualified
name) and NS is absent.
For convenience, expanded names
are sometimes spoken of as matching
a , an , an ,
or other schema component which has both a
and a property (or vice versa,
the component is spoken of as matching
the expanded name), when what is meant
is, strictly speaking, that the expanded namematches the
and
properties of the component.
For any W, the language
L(W)accepted by W
is the set of all sequences of
length 1 whose sole member is an element information item which
matchesW.
An element information item Ematches a W
(or a whose is W)
if and only if E
is locally valid with respect to W, as defined in the validation rule
.
Two namespace
names N1 and N2 are said to match
if and only if they are identical or both are absent.
For principles of validation when the is a model group
instead of a , see
and
.
Element Sequence Locally Valid (Particle)
Element Sequence Locally Valid (Particle)
For a sequence (possibly empty) of element information items to be
locally valid with respect to a
The sequence must be accepted by the , as defined
in .
Element Sequence Accepted (Particle)
Element Sequence Accepted (Particle)
For a sequence (possibly empty) of
element information items to be
accepted by a P,
P. is a
wildcard
The length of the sequence is greater than or
equal to P..
If P. is a number,
then the length of
the sequence is less than or equal to the .
Each element information item in the sequence isvalid with respect to the
wildcard as defined by .
In this case, each
element information item in the sequence is attributed toP and has no .
P. is an
element declarationD
The length of the sequence is greater than or
equal to P..
If P. is a number,
then the length of
the sequence is less than or equal to the
.
For each element information item E in the sequence
D
has the same expanded name as E.
In this case D is the context-determined declaration
for E with respect to
and
.
D is top-level (i.e. D.. = global), its does not contain
substitution, E's
expanded nameresolves to
an element declarationS —
call this declaration the
substituting declaration — and S is
for D as defined in
.
In this case S is the context-determined declaration
for E with respect to
and .
In this case E is attributed toP.
This clause is equivalent to requiring that the sequence
of length 1 containing E is in
L(D).
P. is a model
group
There is a partition of the sequence
into n sub-sequences such that
n is greater than or equal to
P..
If P. is a
number, nis less than or equal to
P..
Each sub-sequence in the partition is valid with respect to that model
group as defined in .
In this case, the
element information items in each sub-sequence are attributed to
within the model group which is the , as described in
.
The rule just given does not require that the
content model be deterministic. In practice, however,
most
non-determinism in content models is ruled out by the schema
component constraint .
Non-determinism can occur despite that constraint for
several reasons.
In some such cases,
some particular element information item may be accepted by either a
or an . In such situations,
the validation process defined in this specification matches the
element information item against the , both in
identifying the as the item's
context-determined declaration,
and in choosing alternative paths through a content model.
Other cases of non-determinism involve nested particles each of
which has greater than 1,
where the input sequence can be partitioned in multiple ways.
In those cases, there is no fixed rule for eliminating the
non-determinism.
and do not
interact: an element information item validatable by a declaration
with a substitution group head is
not validatable by a wildcard which accepts the head's
(namespace, name) pair but not its own.
Particle Information Set Contributions
None as such.
Constraints on Particle Schema Components
Particle Correct
All particles (see ) must satisfy the following constraint.
Particle Correct
The values of the properties of a particle are as described in
the property tableau in
, modulo the impact of .
If is not unbounded, that is, it has a
numeric value, then
is not greater than .
Particle Valid (Extension)
The following constraint
defines a
relation
appealed to elsewhere in this specification.
Particle Valid (Extension)
For a particle
(call it E, for extension) to be a valid extension of
another particle (call it B, for base)
They are the same particle.
E.
= E.
= 1 and E. is a
sequence group whose ' first member is a
particle all of whose properties, recursively, are
identical to those of B.
E. =
B..
Both E and B have all groups
as their s.
The
of B's
all group is a prefix of the of
E's all group.
Particle Emptiable
The following constraint defines a relation appealed
to elsewhere in this specification.
Particle Emptiable
For a particle to be
emptiable
Its is 0.
Its is a group and the minimum part of the
effective total range of that group, as defined by (if
the group is all or sequence) or
(if it is choice), is 0.
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 validation of
attribute and element information items dependent on their namespace
namesand optionally on their local names.
XML representations of the four basic types of wildcard, plus one attribute wildcard.
The Wildcard Schema Component
The wildcard schema component has the following properties:
provides for
validation of attribute and element items that:
(any) have any namespace or are not
namespace-qualified;
(not and
a set whose members are either namespace names or
absent) have any namespace
other than the specified namespaces and/or, if absent is included in the set, are
namespace-qualified;
(see this example, which accepts
only namespace-qualified names distinct from the target namespace; the
##local in the schema document
maps to the value absent in the
property)
(enumeration and 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.
(contains
QName
members) have any expanded name
other than the specified names.
( contains the keyword defined) have any
expanded name
other than those matching the
names of global element or attribute declarations.
( contains the keyword sibling) have
any expanded name other than those
matching the names of element or attribute declarations in
the containing complex type definition.
controls the impact on
of the information items allowed by wildcards, as follows:
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.
No constraints at all: the item must simply be well-formed XML.
If the item has a uniquely
determined declaration available, it must be valid with respect to
that
declaration, that is, validate
if you can, don't worry if you can't.
See for information on the role of the
property.
The keywordsdefinedand
sibling allow a kind of wildcard which matches only
elements not declared in the current schema or contained
within the current complex type,
respectively. They are
new in this version of this specification. The Working Group is
uncertain whether their value outweighs their
liabilities; we solicit input from implementors and users of
this specification as to whether they should be retained or not.XML Representation of Wildcard Schema Components
The XML representation for a wildcard schema component is an
or element
information item.
An information item
corresponds both to a wildcard component and to
a particle containing that wildcard
(unless minOccurs=maxOccurs=0, in which case the
item corresponds to no component at
all).
The mapping rules are given in the following two subsections.
Mapping from
<any> to a Particle
The mapping from an information item to a particle
is as follows.
The actual value of the
minOccursattribute, if present, otherwise
1.unbounded, if
maxOccurs = unbounded,
otherwise the actual value of the
maxOccursattribute, if present, otherwise
1.A wildcard as given
below.
The same annotations as the of the wildcard. See below.
Mapping from
<any>and
<anyAttribute>
to a Wildcard Component
The mapping from an information item to a wildcard component
is as follows. This mapping is also used for mapping
information items to wildcards,
although in some cases the result of the mapping is further
modified, as specified in the rules for
and
.
A with
the following properties:
the namespaceattribute is
present
namespace
= "##any"
any;
namespace
= "##other"
not;
enumeration;
the notNamespaceattribute
is present
not;
(neither namespace nor
notNamespace is present) any.
neither namespace nor
notNamespace is present
the empty set;
namespace = "##any"
the empty set;
namespace
= "##other"
a set consisting of
and, if the targetNamespace [attribute] of
the ancestor element
information item is present, its actual value;
a set whose members are namespace
names corresponding to the space-delimited substrings of
the actual value of the namespace or
notNamespaceattribute (whichever is
present), except
if one such substring is
##targetNamespace, the corresponding
member is the actual value of the
targetNamespaceattribute of the
ancestor
element information item if present, otherwise
;
if one such substring is ##local, the
corresponding member is .
If the notQNameattribute is
present, then a set whose members
correspond to the items in theactual value of the notQNameattribute,
as follows.
If the item is a QName
value (i.e. an expanded name), then that
QName
value is a member of the set.
If the item is the token ##defined,
then the keyword defined is a member of the set.
If the item is the token ##definedSibling,
then the keyword sibling is a member of the set.
If the notQNameattribute is not present, then
the empty set.
The actual value of the
processContentsattribute, if present,
otherwise strict. The of the
element, as defined in .
When this rule is used for an attribute wildcard (see ), the is the
of the
element.
Wildcards are subject to the same ambiguity constraints
() as other content model
particles:
If an instance element could match one
of two wildcards, within the content model of a type, that model
is in error.
Constraints on XML Representations of Wildcards
Wildcard Representation OK
In addition to the conditions imposed on and
element information items by the schema for schema documents, namespace and
notNamespace attributes must not both be
present.
For an element or attribute information item I to be locally valid with respect to a wildcard
W
The expanded name of I is valid with respect to
W., as defined in
.
W..
contains the keyword defined
W is an element wildcard (i.e., W appears in a
content model)
the expanded name of I does not resolve
to an element declaration. (Informally, no such top-level element is
declared in the schema.)
W is an attribute wildcard
the expanded name of I does not resolve
to an attribute declaration.
W..
contains the keyword sibling;
W is an element wildcard
I is an element information item
I has a parentP that is
also an element information item
I and P have the same
P has an T (which is always a complex
type and contains W in its )
the expanded name of I does not any
element declaration contained
in the content model of T, whether
directly,
indirectly, or
implicitly.
Informally, the keyword sibling disallows any element declared as
a possible sibling of the wildcard W.
When an element or attribute information
item is attributed to a wildcard and the preceding constraint
() is satisfied, then the item has no
. Its declaration, if any, is found by matching its
expanded name as described in .
Note that QName resolution is performed only if the item is attributed to
a strict or lax wildcard; if the wildcard has a
property of skip,
then the item has no declaration.
An element or attribute information item is skipped if it
is attributed to a skip wildcard or if one of its ancestor
elements is.
Wildcard allows Expanded Name
Wildcard allows Expanded Name
For an expanded nameE, i.e. a
(namespace name, local name) pair,
to be valid with respect to a
namespace constraint C
The namespace name is valid with respect to
C, as defined in ;
C. does not
contain E.
Wildcard allows Namespace Name
Wildcard allows Namespace Name
For a value V
which is either a namespace name or
absent to be valid with respect to
a
namespace
constraint
C (the
value of a )
C. = any.
C. = not,
and V is not identical to any of the members of
C..
C.
= enumeration, and V is
identical to one of the members of C..
Wildcard Information Set Contributions
None as such.
Constraints on Wildcard Schema Components
Wildcard Properties Correct
All wildcards (see ) must satisfy
the following constraint.
Wildcard Properties Correct
The values of the properties of a wildcard are as
described in the property tableau in
, modulo the impact of
.
If is not,
has at least one member.
If is any, is
empty.
The namespace name of each QName member
in is allowed by the
, as defined in
.
Attribute wildcards do not contain sibling in their
..
Wildcard Subset
The following constraints define a relation appealed to
elsewhere in this specification.
Wildcard Subset
Given two s sub and super,
sub is a wildcard subset of super
if and only if
super. =
any.
Both sub and super
have
= enumeration, and
super.
is a superset of sub..
sub. =enumeration,
super. =not, and the
of the two are disjoint.
Both sub and super
have
= not, and
super. is a subset of
sub..
And
Each QName member
of super. is not
allowed
by sub, as defined in .
If super. contains
defined, then
sub. also contains
defined.
If super. contains sibling, then
sub's also contains sibling.
Attribute Wildcard Union
Attribute Wildcard Union
Given three s O, O1, and O2, O is
the
wildcard union of O1 and
O2 if and only if, first, the and
, and, second, the of
O are consistent
with O being the union of O1 and O2, as that is defined
below.
The and of O are consistent
with O being the wildcard union of O1 and O2 if and
only if
O, O1, and O2 all have
the same and .
Either O1. =
any or O2. =
any, and O. = any.
O, O1, and O2 all have
enumeration, and
O. is the union of
O1.
and O2..
O1. = O2. =
not, and
The intersection of the of O1 and O2 is the
empty set, and O. = any.
O. =
not, and O. is the non-empty
intersection of O1. and
O2..
Either O1 or O2 has =not and =S1, and
the other has =enumeration and
=S2, and
The set difference S1 minus S2 is the empty set, and
O. = any.
O. = not and O. is
the non-empty set difference S1 minus S2.
The property of O is consistent with O being
the wildcard union of O1 and
O2 if and only if O. includes
all and only the
following:
QName members of
O1. that are not allowed by
O2, as
defined in
.
QName
members of O2. that are not
allowed by O1.
The keyword defined if it is contained in both
O1. and
O2..
When one of the wildcards has
defined in and the other does not, then
defined is not included in the union. This may allow
QNames that are not allowed by either wildcard. This is to ensure
that all unions are expressible. If defined is intended to be
included, then it is necessary to have it in both wildcards.
In the case where there are more than two s to be combined, the wildcard
union is determined by identifying the wildcard union of two
of them as above, then the wildcard union of the result with
the third, and so on as required.
Given three s
O, O1, and O2, O is the
wildcard intersection
of O1 and O2 if and only if
both its and properties, on the
one hand, and its property, on the other, are
consistent with O being the intersection
of O1 and O2, as that is defined below.
The and of O are consistent
with O being the wildcard
intersection of O1 and O2 if and only if
O, O1, and O2 have
the same and .
Either O1 or O2 has = any
and O has and identical
to those of the other.
O, O1, and O2 all have = enumeration,
and O.
is the intersection of the
of O1 and O2.
O, O1, and O2 all have
=not,
and O.
is the union of the
of O1 and O2.
Either O1 or O2 has = not
and = S1 and the other has =
enumeration and = S2,
and O. = enumeration and
O. = the
set difference S2 minus S1.
The property of O is consistent
with O being the wildcard
intersection of O1 and O2 if and only if
O.
includes all and only the following:
QName
members of O1.whose namespace names
are allowed by O2, as defined in
.
QName
members of O2.whose namespace names
are allowed by O1.
The keyword defined if it is a member of either
.
In the case where there are more than two s to be combined, the wildcard
intersection is determined by identifying the wildcard intersection of two
of them as above, then the wildcard intersection of the result with
the third, and so on as required.
Identity-constraint Definitions
Identity-constraint definition components provide for uniqueness and
reference constraints with respect to the contents of multiple elements and attributes.
XML representations for the three kinds of identity-constraint definitions.
The Identity-constraint Definition Schema Component
The identity-constraint definition schema component has the following
properties:
Identity-constraint definitions are identified by their and ;
identity-constraint
definition identities must be unique within an XSD schema. See for the use of component
identifiers when importing one schema into another.
Informally, identifies the
identity-constraint
definition as playing one of
three roles:
(unique) the
identity-constraint
definition asserts uniqueness, with respect to the content
identified by , of the tuples resulting from
evaluation of the XPath expression(s).
(key) the
identity-constraint
definition asserts uniqueness as for
unique. key further asserts that all selected content
actually has such tuples.
(keyref) the
identity-constraint
definition asserts a correspondence, with respect to the content
identified by , of the tuples resulting from
evaluation of the XPath expression(s), with those of the .
These constraints are specified along side the specification of types for the
attributes and elements involved, i.e. something declared as of type integer
can also serve as a key. Each constraint declaration has a name, which exists in a
single symbol space for constraints. The
equality and inequality
conditions
appealed to in checking these constraints apply to the
values of
the fields selected, not their
lexical representation, so that for example 3.0 and 3
would be conflicting keys if they were both
decimal, but non-conflicting if
they were both strings, or one was a string and one a decimal.
When equality and
identity differ for the simple types involved, all three
forms of identity-constraint test for equality, not identity,
of values.
Overall the augmentations to XML's ID/IDREF mechanism are:
Functioning as a part of an identity-constraint is in addition to, not instead of,
having a type;
Not just attribute values, but also element content and combinations
of values and content can be declared to be unique;
Identity-constraints are specified to hold within the scope of particular elements;
(Combinations of) attribute values and/or element content can be
declared to be keys, that is, not only unique, but always present and non-nillable;
The comparison between keyref and
key or unique is by value equality,
not by string equality.
specifies a restricted XPath
() expression relative to
instances of the element being declared. This must identify a
sequence of element nodes that are
contained within the declared element
to which the constraint applies.
specifies XPath expressions relative to each
element selected by a .
Each
XPath expression in the propertymust identify
a single node (element or attribute),
whose content or value, which must be
of a simple type, is used in the constraint. It is possible to specify an
ordered list of s, to cater to multi-field keys,
keyrefs, and uniqueness constraints.
In order to reduce the burden on implementers, in particular
implementers of streaming processors, only restricted subsets of XPath
expressions are allowed in and . The details are given in .
Provision for multi-field keys etc. goes beyond what is supported by xsl:key.
In version 1.0 of this specification, identity constraints used
.
They now use .
See for information on the role of the
property.
XML Representation of Identity-constraint Definition Schema Components
The XML representation for an identity-constraint definition schema
component is either a , a or a element information
item. The correspondences between the properties of those
information items and properties of the component they
correspond to are as follows:
If the refattribute is absent,
the corresponding schema
component is as follows:
The actual value of the
nameattributeThe actual value of the
targetNamespaceattribute of the
ancestor
element information item if present, otherwise absent.One of key,
keyref or
unique, depending on the item.
An property record, as described in
section , with
as the "host element" and
xpath as the designated
expression attribute.
A sequence of property records, corresponding to the
element information item children, in order,
following the rules given in ,
with as the "host element"
and xpath as the designated expression attribute.
If the item is a , the
identity-constraint definition resolved to by the
actual value of the referattribute, otherwise
absent.
The of the set of elements containing the
, , or element,
whichever is present, and the and children, if present,
as defined in .
Otherwise (the refattribute is
present), the corresponding schema component is the identity-constraint definition
resolved to by the actual value of the
refattribute.
<xs:element name="vehicle">
<xs:complexType>
. . .
<xs:attribute name="plateNumber" type="xs:integer"/>
<xs:attribute name="state" type="twoLetterCode"/>
</xs:complexType>
</xs:element>
<xs:element name="state">
<xs:complexType>
<xs:sequence>
<xs:element name="code" type="twoLetterCode"/>
<xs:element ref="vehicle" maxOccurs="unbounded"/>
<xs:element ref="person" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<!-- vehicles are keyed by their plate within states -->
<xs:key name="reg">
<xs:selector xpath=".//vehicle"/>
<xs:field xpath="@plateNumber"/>
</xs:key>
</xs:element>
<xs:element name="root">
<xs:complexType>
<xs:sequence>
. . .
<xs:element ref="state" maxOccurs="unbounded"/>
. . .
</xs:sequence>
</xs:complexType>
<!-- states are keyed by their code -->
<xs:key name="state">
<xs:selector xpath=".//state"/>
<xs:field xpath="code"/>
</xs:key>
<xs:keyref name="vehicleState" refer="state">
<!-- every vehicle refers to its state -->
<xs:selector xpath=".//vehicle"/>
<xs:field xpath="@state"/>
</xs:keyref>
<!-- vehicles are keyed by a pair of state and plate -->
<xs:key name="regKey">
<xs:selector xpath=".//vehicle"/>
<xs:field xpath="@state"/>
<xs:field xpath="@plateNumber"/>
</xs:key>
<!-- people's cars are a reference -->
<xs:keyref name="carRef" refer="regKey">
<xs:selector xpath=".//car"/>
<xs:field xpath="@regState"/>
<xs:field xpath="@regPlate"/>
</xs:keyref>
</xs:element>
<xs:element name="person">
<xs:complexType>
<xs:sequence>
. . .
<xs:element name="car">
<xs:complexType>
<xs:attribute name="regState" type="twoLetterCode"/>
<xs:attribute name="regPlate" type="xs:integer"/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
A state element is defined, which
contains a code child and some vehicle and person
children. A vehicle in turn has a plateNumber attribute,
which is an integer, and a state attribute. State's
codes are a key for them within the document. Vehicle's
plateNumbers are a key for them within states, and
state and
plateNumber is asserted to be a key for
vehicle within the document as a whole. Furthermore, a person element has
an empty car child, with regState and
regPlate attributes, which are then asserted together to refer to
vehicles via the carRef constraint. The requirement
that a vehicle's state match its containing
state's code is not expressed here.
A list of state elements can appear as child elements
under stateList. A key constraint can be used to
ensure that there is no duplicate state code. We already
defined a key in the above example for the exact same purpose
(the key constraint is named "state"). We can reuse it
directly via the ref attribute on the key
element.
Constraints on XML Representations of Identity-constraint Definitions
Identity-constraint Definition Representation OK
In addition to the conditions imposed on , and element
information items by the schema for schema documents,
One of ref or name is present, but not both.
If name is present, then appears in
children.
If name is present on , then
refer is also present.
If ref is present, then only id
and are
allowed to appear together with ref.
If ref is present, then the
of the identity-constraint
definition resolved to by the
actual value of the refattribute matches the name of the
element information item.
For an element information item E
to be locally valid with respect to an identity-constraint
A data model instance is constructed
from the input information set, as described in .
The , with
the element node corresponding to E as the
context node, evaluates to a
sequence of element nodes, as defined in
.
The target node set is the
set of nodes in that sequence, after omitting
all element nodes corresponding to element
information items that are
.
Each node in the target node set is
either the context node
or an
element node among its descendants.
For each node in the target node set all of the , with
that node as the context node, evaluates to
a
sequence of nodes (as defined in
) that only contains
nodes and at most one node whose
type definition is either a simple type definition or a complex type
definition with simple.Call the
sequence of the
schema actual values
of the element and/or attribute information items in
those node-sets in order the key-sequence of the
node.
The use of schema actual value in the definition
of key sequence above means that
default or fixed value constraints may play a part in key sequences.
The qualified node set is the subset
of the target node set consisting of those nodes for
which all the evaluate to a node sequence
one of whose members is an element or attribute node with a
non-absentschema actual value.
the is unique
no two members of the qualified node set have key-sequences whose members
are pairwise equal, as defined by Equality in .
the is key
The target node set and the qualified node set are equal, that is, every member of the target node set is also a member of the qualified node set and vice versa.
No two members of the qualified node set have key-sequences whose members
are pairwise equal, as defined by Equality in .
No element member of the key-sequence of any
member of the qualified node set was assessed as valid by reference to an element
declaration whose is true.
the is keyref
for each member of the
qualified node set (call this
the keyref member), there is a
node table associated
with the
in the of E
(see , which is understood
as logically prior to this clause of this constraint,
below) and there is an entry in that table whose
key-sequence is equal to
the keyref member'skey-sequence member for member,
as defined by Equality
in .
For unique identity constraints, the qualified node set is
allowed to be different from the target node set. That is, a
selected unique node may have fields that do not have corresponding
schema actual values.
Because the validation of keyref (see ) depends on finding appropriate entries in a
element information item's node
table, and node
tables are assembled strictly recursively from the
node tables of descendants, only element information items
within the sub-tree rooted at the element information item
being validated can be referenced successfully.
Although this specification defines a post-schema-validation infoset contribution
which would enable schema-aware processors to implement
above (), processors are not required to provide
it. This clause can be read as if in the absence of this
infoset contribution, the value of the relevant
property must be available.
For purposes of checking
identity-constraints, single atomic values are not distinguished
from lists with single items. An atomic value V and a list
L with a single item are treated as equal, for
purposes of this specification, if V is equal
to the atomic value which is the single item of L.
Identity-constraint Definition Information Set Contributions
Identity-constraint Table
An
eligible identity-constraint of an element information item is
one such that or of
is satisfied with respect to that
item and that constraint, or such that any of the element information
item children of that item have an property whose value has an entry for
that constraint.
A node
table is a set of pairs each consisting of a key-sequence and an element node.
Whenever an element information item has one or more eligible identity-constraints, in the post-schema-validation infoset that
element information item has a property as follows:
one
Identity-constraint Binding
information item for each eligible identity-constraint, with
properties as follows:
The eligible identity-constraint.A node table with one entry for every key-sequence (call it k) and
node (call it n) such that
There is an entry in one of the node
tables associated with the in an Identity-constraint Binding
information item in at least one of the s of the element information item
children of the element information item whose key-sequence is k and whose node
is n;
n appears with key-sequencek in the qualified node set for the .
provided no two entries have the same key-sequence but distinct nodes. Potential
conflicts are resolved by not including any conflicting entries which
would have owed their inclusion to above. Note
that if all the conflicting entries arose under above, this means no entry at all will appear for the
offending key-sequence.
The complexity of the above arises from the fact that
keyref identity-constraints can be defined on domains distinct from the
embedded domain of the identity-constraint they reference, or on domains which are the
same but self-embedding at some depth. In either case the node
table for the referenced identity-constraint needs to propagate upwards, with
conflict resolution.
The Identity-constraint Binding information item, unlike
others in this specification, is essentially an internal bookkeeping
mechanism. It is introduced to support the definition of
above.
Constraints on Identity-constraint Definition Schema Components
Identity-constraint Definition Properties Correct
All identity-constraint definitions (see ) must satisfy the
following constraint.
Identity-constraint Definition Properties Correct
The values of the properties of an identity-constraint definition
are as described in the property tableau in
, modulo the
impact of .
If the
is keyref, the cardinality of the is equal
to that of the
of the .
Selector Value OK
Selector Value OK
The satisfies the constraint
.
Its
conforms to the following extended BNF:
Selector XPath expressions
SelectorPath ( '|' Path )*Path('.//')? Step ( '/' Step )*Step'.' | NameTestNameTestQName | '*' | NCName ':' '*'
Its is an XPath expression
involving the child axis whose abbreviated
form is as given above.
For readability, whitespace may be used in selector XPath
expressions even though not explicitly allowed by the grammar:
whitespacemay be freely added
within patterns before or after any token.
Lexical productions
token'.' | '/' | '//' | '|' | '@' | NameTestwhitespaceS
When tokenizing, the longest possible token is always returned.
The subset of XPath defined in
is called the
selector subset of XPath.
Fields Value OK
Fields Value OK
Each member of the satisfies the constraint
.
For each member of the
Its conforms to the extended BNF given
above for Selector, with the following modification:
Path in Field XPath expressions
Path('.//')? ( Step '/' )* ( Step | '@' NameTest )
This production differs from the one above in allowing the final
step to match an attribute node.
Its is an XPath expression involving the child and/or attribute axes whose abbreviated form is
as given above.
For readability, whitespace may be used in field XPath expressions even though not
explicitly allowed by the grammar: whitespacemay be freely added within patterns before or after any token.
When tokenizing, the longest possible token is always returned.
The subset of XPath defined in
is called the
field subset of XPath.
Type Alternatives
Type Alternative components provide associations between boolean
conditions (as XPath expressions) and s.
They are used in conditional type assignment.
The Type Alternative Schema Component
The type alternative schema component has the following properties:
Type alternatives can be used by an to specify a
condition () under which a particular type () is used
as the
for element information items governed by that
. Each may have multiple
s in its .
XML Representation of Type Alternative Schema Components
The XML representation for a type
alternative schema component is an
element information item. The correspondences
between the properties of that information item and properties of the
component it corresponds to are as follows:
Each element
maps to a component as follows.
If the testattribute is not present, then absent;
otherwise an property record, as described in
section
, with
as the "host element"
and test as the designated expression attribute.
The type definition resolved to by the actual value of the typeattribute, if one is present, otherwise the type definition corresponding
to the complexType or simpleType among the
children of the element.
The of the element,
as defined in .
Constraints on XML Representations of Type AlternativesType
Alternative Representation OK
In addition to the conditions imposed
on
element information items by the schema for schema documents,
every element must have
a type
attribute, or a complexType child element, or a
simpleType child element. Each
element
must have
one and only one of these.
Type Alternative Validation Rules
A Asuccessfully selects a T for an
element information item E if and only if A. evaluates to
true and A. = T.
The is evaluated in the following way:
An instance of the data model is constructed as
follows:
An information set is constructed by copying
the base information set properties
(and not any of the properties specific to post-schema-validation infoset) of the following
information items:
E itself.
E's attributes (but not its children).
E's which do not
have the same expanded names as any of E's attributes.
They are copied as if they were among E's attributes and had
E as their owner element.
When an attribute with a non-empty
namespace name is copied, may need to be performed on the
resulting information set to ensure that a prefix P is bound to
the namespace name and the prefix of
the copied attribute is set to P.
An data model instance is constructed from
that information set, following the rules given in
.
The XPath expression
which is the value of the , is evaluated
as described in .
If a
dynamic error or a
type error is raised during
evaluation, then the is
treated as if it had evaluated (without
error) to false.
Dynamic errors and
type errors in the evaluation of
expressions cause neither the schema nor the document instance to
be invalid. But conforming processors may issue a warning if they occur.
As a consequence of the rules just given, the root node of the
instance is necessarily constructed from
E;
the ancestors,
siblings, children, and descendants of E are
not represented in the data model instance, and they are thus
not accessible to the tests expressed in the s in the
. The element E and itsattributes will be
represented in the data model instance by nodes labeled as
untyped. If the expressions being evaluated include
comparisons which require type information, then explicit casts
will sometimes be necessary.
Type Alternative Information Set Contributions
None.
Constraints on Type Alternative Schema Components
All type alternatives (see ) must
satisfy the following constraints.
Type Alternative Properties Correct
The values of the properties of a type alternatives
are as
described in the property tableau in ,
modulo the impact of .
If the is not absent, then it satisfies the constraint
.
The function
signatures in the static contextmust include signatures for
The fn:not function
defined in the specification.
Constructor functions for the built-in datatypes.
The further contents of function
signatures are implementation-defined.
A conforming processor must accept and process any XPath expression
conforming to the "required subset" of defined
by the following grammar.
Any XPath expression valid according to may
appear in a conforming schema. Conforming processors may but are not
required to support XPath expressions not belonging to the required
subset of XPath.
An XPath expression belongs to the required subset of XPath if and only
if
The property of the
is a valid XPath expression, as defined in
.
It is an XPath expression involving the attribute axis
whose abbreviated form is as given above.
For readability, allows whitespace to be
used between tokens in XPath expressions, even though this is not
explicitly shown in the grammar. For details of whitespace handling,
consult .
Any strings matching the BooleanFunction
production are function calls to fn:not
defined in the specification.
Any strings matching the ConstructorFunction
production are function calls to constructor functions for the built-in
datatypes.
The minimal content of the function
signatures in the static context
is given in
of : fn:not and
constructors for the built-in datatypes.
The above extended BNF is ambiguous. For example, the string
"a:b('123')" has 2 paths in the grammar, by matching either
BooleanFunction or
ConstructorFunction. The rules given
here require different function names for the productions. As a result, the
ambiguity can be resolved based on the function name.
Any explicit casts (i.e. any strings which match
the optional cast asQName in the
CastExpr production)
are casts to built-in datatypes.
Implementations may choose to support a bigger subset of
.
The rule given above for the construction of the data model
instance has as a consequence that even when implementations
support full expressions, it is not
possible to refer successfully to the children, siblings,
ancestors, etc. of the element whose type is being selected.
Assertions
Assertion components constrain the existence and values of related
elements and attributes.
<xs:assert test="@min le @max"/>
The XML representation
for assertions.
The element requires that the
value of the min attribute be less than or equal to that of the
max attribute, and fails if that is not the case.
The Assertion Schema Component
The assertion schema component has the following properties:
To check an assertion,
an instance of the XPath 2.0 data
model () is constructed, in which the element
information item being assessed
is the root element, and
elements and attributes are assigned types and values according to
XPath 2.0 data model construction rules, with some exceptions. See
for details about how the data model is
constructed.When evaluated against this data model
instance, evaluates to either
true
or false (if any other value is returned, it's converted to
either true or false as if by a call to the XPath
fn:boolean function).
See for information on the role of
the property.
XML Representation of Assertion Schema Components
The XML representation for an assertion schema component
is
an
element information item.
The correspondences between the properties of
that information item and
properties of the component
it corresponds to are as follows:
The element
maps to an component as follows.
An property record, as described below,
with as the "host element"
and test as the designated expression attribute.
The of the
element,
as defined in .
Assertions, like identity constraints and conditional type
assignment, use expressions.
The expression itself is recorded, together with relevant parts
of the context, in an property record.
The mapping is as described below; in each case, the XPath
expression itself is given in a designated attribute of
the appropriate "host element".
A set of property records. Each member
corresponds to an entry in the in-scope namespaces of
the host element, with
being the prefix
and the namespace
name.
Let D be the actual value of the
xpathDefaultNamespaceattribute, if
present on the host
element, otherwise that of the
xpathDefaultNamespaceattribute of
the ancestor. Then
the value is
D is
##defaultNamespace
there is an entry in the
in-scope namespaces of the host element whose prefix
is absent
the corresponding namespace
name;
absent;
D is
##targetNamespace
the targetNamespaceattribute is present on the
ancestor
its actual value;
absent;
D is ##local
absent;
(D is an xs:anyURI
value) D.
The base
URI of the host element.
An XPath expression corresponding to the actual value of the
designated attribute of the host element.
<xs:complexType name="intRange">
<xs:attribute name="min" type="xs:int"/>
<xs:attribute name="max" type="xs:int"/>
<xs:assert test="@min le @max"/>
</xs:complexType>
The value of the min attribute must be less than or equal to
that of the max attribute.
Note that the attributes are validated before the assertion
on the parent element is checked, so the typed values of the attributes
are available for comparison; it is not necessary to cast the values
to int or some other numeric type before comparing them.
An element information item
Eis locally valid with respect to an
assertion if
and only if the
evaluates to true (see below) without raising
any dynamic error
ortype
error.
Evaluation of is performed as defined
in , with the following conditions:
A data model
instance (see )
is constructed in the following way:
E is validated
with respect to its , as defined
in , if the exists, otherwise
against
its , as defined in ,
except that for E itself (though not for its element
information item descendents), of
is skipped. (Informally,
the element is validated normally,
except that assertions are not checked.)
It is a consequence of this rule that the attributes and children
of E will be validated in the usual way.
A partialpost-schema-validation infoset describing the results
of this partial validation
of E is constructed. The post-schema-validation infoset properties
of E's children and attributes are defined in the
usual way. On E itself, all post-schema-validation infoset
properties are supplied as described elsewhere in this specification
if their values are known. The element's
property is given
the value invalid if and only if the element is known
to be invalid; otherwise it is given the value notKnown.
The element's property
is given the value partial.
Since the assertions of its have not been
checked, E has been only partially
validated, and can be known to be invalid, but not known to be
valid. The values of the
and properties
are set accordingly.
From the partialpost-schema-validation infoset, a data model
instance is constructed as described in .
The root node of the instance is
constructed from E; the data model instance contains only
that node and nodes constructed from the attributes,
children, and descendants of E.
It is a consequence of this construction that attempts
to refer, in an assertion, to the siblings or ancestors of
E, or to any part of the input document outside of E
itself, will be unsuccessful.
Such attempted references
are not in themselves errors, but the data model instance
used to evaluate them does not include any representation
of any parts of the document outside of E, so they
cannot be referred to.
The XPath expression is evaluated, following the rules
given in , with the
following
conditions and modifications:
The root node of the instance
described in serves as the context
node for evaluation of the XPath
expression.
The static context
is augmented with the variable $value,
as described in
.
The variable $value appears as a member
of the variable values in
the dynamic context. The
expanded QName of that member has no namespace URI and has
value as the local name.
The value of the member is determined by
E's in the partialpost-schema-validation infoset is not invalid;
E's in the partialpost-schema-validation infoset
does not exist or has value false;
the of E's
has simple,
the value is the
XDM representation of
E.
under the
.
of E's .
This clause provides type information to simple contents
of elements, to make type-aware comparisons and
operations possible without explicit casting in the
XPath expressions.
For complex types with simple content, the element node
may be referred to as ., while
its content may be referred to as
$value. Since the element node,
as a consequence of , will normally have the type
annotation anyType, its atomized
value will be a single atomic value of type
untypedAtomic. By contrast,
$value will be a sequence of one or more
atomic values, whose types are the most specific
(narrowest) built-in types available.
(in the partialpost-schema-validation infoset,
E. = invalid
or
E. = true
or
E's does not have
. = simple)
the value is the empty sequence.
The evaluation result
is converted to either true
or false as if by a call to the XPath
fn:boolean function.
Although the rules
just given describe
how an post-schema-validation infoset and a
instance are constructed, processors are not required
to construct
actual data structures representing them.
However, the result of XPath evaluation must be the same as if such
post-schema-validation infoset and instance
data structures were
constructed.
XPath Evaluation
XPath Evaluation
An property record X, with a context node E,
is evaluated as defined in ,
with a
static context
as described in (unless otherwise specified
elsewhere)
and with the following
dynamic context
(again, unless otherwise specified
elsewhere):
The context item is
E.
The context position
is 1.
The context size is
1.
The variable values is
the empty set.
The function
implementations include an implementation of every function
in thefunction
signatures of the
static context.
See .
The current dateTime is
implementation-defined, but is constant during an
episode.
The implicit timezone is
implementation-defined, but is constant during an
episode.
The available documents is
the empty set.
The available collections is
the empty set.
The default collection is
the empty sequence.
does not currently require support
for theprecisionDecimal datatype,
but conforming XPath processors are allowed to support additional primitive
data types, including precisionDecimal.
For interoperability, it is recommended that XPath processors
intending to support precisionDecimal as an additional
primitive data type follow the recommendations in . If the XPath processor used to
evaluate XPath expressions supports precisionDecimal, then any
precisionDecimal values in the post-schema-validation infosetshould be labeled as
xs:precisionDecimal in the data model instance
and handled accordingly in XPath.
If the XPath processor does not support precisionDecimal,
then any precisionDecimal
values in the post-schema-validation infosetshould be mapped intodecimal, unless the
numericalValue
is not a decimal number (for example, it is
positiveInfinity,
negativeInfinity, or notANumber),
in which case
they should be mapped tofloat.
Whether this is done by altering the type information in the
partial post-schema-validation infoset, or by altering the usual rules for mapping
from a post-schema-validation infoset to an data model instance,
or by treating precisionDecimal as an unknown type which is
coerced as appropriate into decimal or float by the XPath
processor, is implementation-defined and out of scope for this
specification.
As a consequence of the above variability, it is possible
that XPath expressions that perform various kinds of type
introspections will produce different results when different
XPath processors are used. If the schema author wishes to
ensure interoperable results, such introspections will need to
be avoided.
Assertion Information Set Contributions
None as such.
Constraints on Assertion Schema Components
All assertions (see ) must
satisfy the following constraints.
The values of the properties of an assertion are as
described in the property tableau in ,
modulo the impact of .
The satisfies the constraint
,
with the following modifications to the
static context:
The in-scope variables
is a set with a single member. The expanded QName of that
member has no namespace URI and has value as the local
name. The (static) type of the member is
anyAtomicType*.
The function signatures
includes signatures for
Functions in the http://www.w3.org/2005/xpath-functions
namespace as defined in the specification.
Constructor functions for the built-in datatypes.
The XDM type label anyAtomicType* simply says
that for static typing purposes the variable $value
will have a value consisting of a sequence of zero or more
atomic values.
XPath Valid
XPath Valid
For an property record X
to be valid,
The of Xis a valid XPath
expression, as defined in .
X does not produce any static
error, under the following conditions
(except as specified elsewhere):
The Static Typing
Feature is disabled.
The static context is
given as follows:
XPath 1.0
compatibility mode is false.
The statically
known namespaces is the
of X.
The default element/type
namespace is the
of X.
The default function
namespace is http://www.w3.org/2005/xpath-functions.
The in-scope schema definitions
are those components that are present in every schema by definition,
as defined in ,
and .
The in-scope variables
is the empty set.
The context item
static type is not applicable, because the
Static Typing
Feature is disabled.
The function
signatures are implementation-defined.
If X belongs to an or a ,
and
impose additional constraints on the set of required functions.
The statically known
collations are implementation-defined, but always include the
Unicode
codepoint collation
(http://www.w3.org/2005/xpath-functions/collation/codepoint)
defined by .
The default collation
is the Unicode codepoint collation.
The base URI is the
of X.
The statically known
documents is
the empty set.
The statically known
collections is implementation-defined.
The statically
known default collection type is implementation-defined.
Notation Declarations
Notation declarations reconstruct XML NOTATION declarations.
The notation declaration schema component has the following
properties:
Notation declarations do not participate in validation as such. They are referenced in the
course of validating strings as
members of the NOTATION simple type. An element or attribute information item with
its type definition or its
actual member type definition
derived from the NOTATION
simple type is valid only if its
value was among the enumerations of such simple type.
As a consequence such a value is required to be the
of a notation declaration.
See for information on the role of the
property.
XML Representation of Notation Declaration Schema Components
The XML representation for a notation declaration schema component is
a
element information item. The correspondences between the
properties of that information item and
properties of the component it corresponds to are as follows:
The element
maps to a component as follows.
The actual value of the
nameattributeThe actual value of the
targetNamespaceattribute of the
ancestor
element information item if present, otherwise absent.The actual value of the systemattribute, if present, otherwise absent.The actual value of the publicattribute, if present, otherwise absent.
The of the
element,
as defined in .
<xs:notation name="jpeg"
public="image/jpeg" system="viewer.exe" />
<xs:element name="picture">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:hexBinary">
<xs:attribute name="pictype">
<xs:simpleType>
<xs:restriction base="xs:NOTATION">
<xs:enumeration value="jpeg"/>
<xs:enumeration value="png"/>
. . .
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<picture pictype="jpeg">...</picture>
Constraints on XML Representations of Notation Declarations
None as such.
Notation Declaration Validation Rules
None as such.
Notation Declaration Information Set Contributions
Validated with Notation
Whenever an attribute information item is valid with respect to a NOTATION, in the post-schema-validation infoset its
parent element information item has the following
properties:
An item isomorphic to the notation declaration
resolved to by the
attribute item's actual valueThe value of the of that notation
declaration.The value of the of that notation
declaration.
For compatibility, only one such attribute should appear
on any given element. If more than one such attribute
does appear, which one supplies the infoset property or
properties above is not defined.
Element as well as attribute information items may be valid with respect to a NOTATION, but only attribute
information items cause a notation declaration to appear in the
post-schema-validation infoset as a property of their parent.
Constraints on Notation Declaration Schema Components
All notation declarations (see ) must satisfy the following
constraint.
Notation Declaration Correct
The values of the properties of a notation declaration must
be as described in the property tableau in
, modulo the impact of
.
Annotations
Annotations provide for human- and machine-targeted annotations of
schema components.
<xs:simpleType fn:note="special">
<xs:annotation>
<xs:documentation>A type for experts only</xs:documentation>
<xs:appinfo>
<fn:specialHandling>checkForPrimes</fn:specialHandling>
</xs:appinfo>
</xs:annotation>
XML representations of three kinds of annotation.
The Annotation Schema Component
The annotation schema component has the following
properties:
is intended for human consumption,
for automatic processing. In both
cases, provision is made for an optional URI reference to supplement the local
information, as the value of the source attribute of the
respective element information items. validation does not involve dereferencing these URIs, when present. In the case of , indication should be given as to the identity of the (human) language used in the contents, using the xml:lang attribute.
ensures that when schema authors take
advantage of the provision for adding attributes from namespaces other than the
XSD namespace to schema documents, they are available within the components
corresponding to the element items where such attributes appear.
Annotations do not participate in validation as such. Provided an annotation
itself satisfies all relevant Schema
Component Constraints it cannot affect the
validation of element information
items.
The name covers all the different kinds of component which may
have annotations.
XML Representation of Annotation Schema Components
Annotation of schemas and schema components, with material for human or
computer consumption, is provided for by allowing application information and
human information at the beginning of most major schema elements, and anywhere
at the top level of schemas. The XML representation for an annotation schema component is
an
element information item. The correspondences between the
properties of that information item and
properties of the component it corresponds to are as follows:
The element and its
descendants map to an component as follows.
A sequence of
the element information items from
among the children, in order, if any, otherwise the empty
sequence.A sequence of the
element information items from
among the children, in order, if any, otherwise the empty
sequence.A set of attribute information items,
namely those allowed by the attribute wildcard in the type
definition for the item itself or
for the
enclosing items which correspond to the component within which
the annotation component is located.
The annotation component corresponding to the element in the example above will have one
element item in each of its and and one attribute
item in its .
Virtually every kind of schema component defined in this specification
has an annotations property. When
the component is described in a schema document, the mapping from
the XML representation of the component to the
components in the appropriate annotations
property follows the rules described in the next paragraph.
The annotation
mapping of a set of element information items ES
is a sequence of annotations AS, with the following properties:
For every element information item among the
children of any element information item in ES, there
is a corresponding component in AS.
As noted above,
the property of
each component includes
all
the attribute information items on the
element itself, on the
XML element which represents (and maps to) the
component being annotated, and on any intervening
XML elements, if those attribute information items
have namespace names
different from the XSD namespace.
If any element information item E in ES has any attribute information items
A such that
A is in E.attributes.
A.namespace name
is present and not the XSD namespace.
A is not included in the attributes property
of any annotation component described in
.
then for each such E, an component
C will appear in AS, with
C.
and
C.
each being the empty sequence and
C.
containing all and only those attribute information
items A among E.attributes.
AS contains no other components.
The annotation
mapping of a single element information item is the
of the singleton set containing that
element.
The order of components within the sequence
is implementation-dependent.
When the input set has more than one
member, the components in the resulting sequence
do not record which element in the set they
correspond to. The attribute information items in the
of any
similarly do not indicate which element information item in the
schema document was their parent.
Constraints on XML Representations of Annotations
None as such.
Annotation Validation Rules
None as such.
Annotation Information Set Contributions
None as such:
the addition of annotations to the post-schema-validation infoset is
covered by the post-schema-validation infoset contributions of the enclosing components.
Constraints on Annotation Schema Components
All annotations (see ) must satisfy the following constraint.
Annotation Correct
The values of the properties of an annotation must be as described in
the property tableau in
, modulo the impact of .
Simple Type Definitions
This section consists of a combination of copies of
normative material from , for local cross-reference
purposes, and material
unique to this specification, relating to the interface between schema
components defined in this specification and the simple type definition component.
Simple type definitions provide for constraining character information item children of element and attribute
information items.
The XML representation of a simple type definition.
The Simple Type Definition Schema Component
The simple type definition schema component has the following properties:
Simple types are identified by their and . Except
for anonymous simple types (those with no ), since
type definitions (i.e. both simple and complex type definitions taken together) must be uniquely identified within an XSD schema, no simple type definition can have the same name as another
simple or complex type definition. Simple type s and s
are provided for reference from
instances (see ), and for use in the XML
representation of schema components
(specifically in and ). See for the use of component
identifiers when importing one schema into another.
The of a simple type is not ipso
facto the (local) name of the
element or attribute information items validated by that definition. The connection between a
name and a type definition is described in and .
A simple type definition with an empty specification for can be used as the
for other types derived by either of
extension or restriction, or as the in
the definition of a list, or in the of
a union; the explicit values extension, restriction,
list and union prevent further
derivations by extension (to yield a complex type) and restriction (to yield a
simple type) and use in constructing lists and unions respectively.
determines whether the simple type corresponds to
an atomic, list or union type as defined by .
As described in , every simple type definition is
a restriction of some other simple
type (the ), which is xs:anySimpleType if and only if the type
definition in question is xs:anyAtomicType or a list or
union type definition which is not itself derived by restriction from a
list or union respectively.
A type definition
has xs:anyAtomicType as its if and only if it is one of the primitive datatypes. Each
atomic type is ultimately a restriction of exactly one such
primitive datatype, which is its .
The property
contains a set of constraining facets which are used to specify
constraints on the datatype described by the simple type definition.
For atomic definitions, these are restricted
to those appropriate for the corresponding . Therefore, the value space
and lexical space (i.e. what is validated by any atomic simple
type) is determined by the pair (, ).
Constraining facets are defined in . All conforming
implementations of this specification must support all of the
facets defined in . It is implementation-defined whether additional
facets are supported; if they are, the implementation must
satisfy the rules for implementation-defined facets
described in .
As specified in , list simple type definitions validate space separated tokens, each of
which conforms to a specified simple type definition, the . The item type specified
must not itself be a list type, and must be one of the types identified in as a
suitable item type for a list simple type. In this case the
apply to the list itself, and are restricted to those appropriate for lists.
A union simple type definition validates strings which satisfy at
least one of its . As in the case of
list, the
apply to the union itself, and are restricted to those appropriate for unions.
xs:anySimpleTypeor xs:anyAtomicTypemustnot be named as the of any user-defined
atomic simple type definitions:
as they allow no constraining facets, this
would be incoherent.
See for information on the role of the
property.
XML Representation of Simple Type Definition Schema Components
This section reproduces a version of material from , for
local cross-reference purposes.
The element and its descendants
normally, when there are no errors, map to a
component. The case in which
an unknown facet is used in the definition of a simple type
definition is handled specially: the
in question is not in error, but it does not map to any component at all.
The effect of the special handling of unknown facets is to
ensure (1) that implementation-defined facets which are not supported by
a particular implementation result in the types which depend upon them
not being present in the schema, and (2) that the presence of
references to unknown facets in a schema document does not prevent
the rest of the schema document being processed and used.
The following subsections define one set of common mapping
rules for simple type definitions, and three specialized
sets of mapping rules for atomic, list, and union datatypes,
respectively.
If the element
has a element among its children,
and the base type definition has = atomic,
then the mapping rules in
and
apply.
If the element
has a element among its children,
or if it has a child
and the base type definition has = list,
then the mapping rules in
and
apply.
If the element
has a element among its children,
or if it has a child
and the base type definition has = union,
then the mapping rules in
and
apply.
Common mapping rules for Simple Type Definitions
The following rules apply to all
simple type definitions.
The actual value of the nameattribute
if present on the element,
otherwise absent.The actual value of the
targetNamespaceattribute of
the ancestor
element information item if present,
otherwise absent.
the alternative is chosen
the type definition resolved to by the
actual value of the baseattribute of , if present, otherwise the
type definition corresponding to the among
the children of .
the or alternative is chosen
xs:anySimpleType.
A subset of
{restriction, extension, list,
union}, determined as follows.
Let
FS be
the actual value of the
finalattribute,
if present, otherwise the actual value of the
finalDefaultattribute of the ancestor
schema element,
if present, otherwise the empty string. Then the property value is
FS is the empty string
the empty set;
FS is
#all
{restriction, extension, list,
union};
Consider FS as
a space-separated list, and include restriction if
restriction is in that list, and similarly for
extension, list and union.
the
nameattribute is present
absent
the parent element information item is
the corresponding
the parent element information item is
the corresponding
the parent element information item is or
the
corresponding to the grandparent element information item
(the parent element information item is ),
the grandparent element information item is
the
corresponding to the grandparent
(the grandparent element information item is ),
the which is the
of the
corresponding to the great-grandparent element information item.
If the alternative is chosen,
then list, otherwise if the alternative is
chosen, then union, otherwise (the
alternative is chosen), then the
of the .
the alternative is chosen
the children of the element are all
either elements,
elements,
or elements which specify constraining facets
supported by the processor
the set of
components
obtained by
overlaying
the of the
with the
set of components
corresponding to those children of
which specify facets, as defined in .
the alternative is chosen
the children of the element
include at least one element of which the processor has no
prior knowledge (i.e. not a element,
an element, or an element
denoting a constraining facet known to and
supported by the processor)
the element
maps to no component at all (but is not in error solely on account of
the presence of the unknown element).
the alternative is chosen
a set with one member, a facet with
value = collapse and fixed = true.
the empty set
Based on
, ,
and , a set of components, one
each as specified in The ordered Schema Component , The bounded Schema Component ,
The cardinality Schema Component and The numeric Schema Component .
The of the set of elements containing the
, and one of
the ,
or children,
whichever is present,
as defined in .
Mapping Rules for Atomic Simple Type Definitions
The following rule applies if the is atomic
The
ancestors of a
type definition are its
and the
ancestors of its
.
(The ancestors of a
T in the type hierarchy are themselves
type definitions; they are distinct from
the XML elements which may be ancestors, in the XML document
hierarchy, of the element which
declares T.)
From among the ancestors of this , that which corresponds to a primitive datatype.
Mapping Rules for Lists
If the is list, the following additional
property mapping
applies:
the is xs:anySimpleType
the (a) resolved
to by the
actual value of the itemTypeattribute of ,
or (b), corresponding to the among
the children of , whichever is present.
In
this case, a element will invariably be present; it will
invariably have either an itemTypeattribute or a child, but not both.
(that is, the is not xs:anySimpleType), the of the .
In this case, a element will invariably
be present.
Mapping Rules for Unions
If the
is union, the following
additional property mapping applies:
the is xs:anySimpleType
the sequence of
s (a)
resolved to by the items in the
actual value of the memberTypesattribute of ,
if any, and (b)
corresponding to the s among
the children of , if any, in order.
In
this case, a element will invariably be present; it will
invariably have either a memberTypesattribute or one or more children, or both.
(that is, the is not xs:anySimpleType), the of the .
In this case, a element will invariably
be present.
Constraints on XML Representations of Simple Type Definitions
Simple Type Definition Representation OK
In addition to the conditions imposed on element information items by the schema for schema documents,
With the exception of ,, and ,
the children of do
not contain more than one element information item with the same
name.
If the alternative is chosen,
it haseither a baseattribute
or a among its children, but not
both.
If the alternative is chosen,
it haseither an itemTypeattribute
or a among its children,
but not both.
If the alternative is chosen, either it
has a non-empty memberTypesattribute or it
has at least one simpleTypechild.
Simple Type Definition Validation Rules
String Valid
For a string S
to be locally valid with respect to a simple type definition
T
The normalized value of S, N, is calculated using
the whiteSpace facet, and any other pre-lexical facets associated with T, as described in the definition
of the term normalized value.
N is schema-valid with respect to
T as
defined by Datatype
Valid in .
T is ENTITY or is validly
derived from ENTITY, as
defined in
Nis a declared entity name.
T is ENTITIES or is
validly derived from ENTITIES, as
defined in
every whitespace-delimited substring of
Nis
a declared entity
name.
no further condition applies.
A string is a
declared entity name if and only if it is equal to the name
of some unparsed entity information item in the value of the unparsedEntities
property of the document information item at the root of the infoset
containing the element or attribute information item whose normalized value
the string is.
Simple Type Definition Information Set
Contributions
None as such.
Constraints on Simple Type Definition Schema Components
Simple Type Definition Properties Correct
All simple type definitions must satisfy both
the following constraints.
Simple Type Definition Properties Correct
The values of the properties of a simple type
definition are as described in the property tableau in
The Simple Type Definition
Schema Component, modulo the impact of
.
All simple type definitions are, orarederived
ultimately from,xs:anySimpleType (so circular
definitions are disallowed). That is, it is possible
to reach a primitive datatype or xs:anySimpleType by
following the zero or more
times.
The of the does not
contain restriction.
There is not
more than one member of
of the same kind.
Each member of is
supported by the processor.
As specified normatively elsewhere, all conforming
processors must support the facets defined by
; support for additional facets is implementation-defined.
If a schema document applies an unknown facet,
the immediate result will be a violation of this constraint,
so that the simple type defined by means of that facet
will be excluded from the schema, and any references to it
will be treated as undischarged references.
Either D is
xs:anyAtomicType, or else B is an atomic simple type
definition.
The type
xs:anyAtomicType is an exception because its
is xs:anySimpleType, whose
is .
B.does not contain restriction.
For each facet in D.
(call this DF)
DFisapplicable to
D, as specified in
Applicable
Facets of .
DF satisfies the constraints
on facet components given in the appropriate subsection of
Constraining Facets
in .
D.
= list
EitherD..=atomic or D.. =unionandthere
are no
types whose is list among
the union's transitive
membership.
B
is xs:anySimpleType
D..does not contain list.
D.contains only the
whiteSpace facet component
with value
= collapse and
fixed
= true.
B.
= list.
B.does not contain restriction.
D.is validly derived from
B., as defined in
.
All facets in
are applicable to D, as specified in
Applicable
Facets.
All facets in
satisfy the constraints on facet components given in the appropriate subsection
of Constraining Facets.
The first case above will apply when a list is constructed by
specifying an item type, the second when derived by restriction from another list.
D.
is union
B is xs:anySimpleType
All of the have a
which does not contain union.
D.is empty.
B.
= union.
B.does not contain
restriction.
Each type definition in
D.
is validly derived from the corresponding type definition in
B., as
defined in .
All facets in
are applicable to D, as specified in
Applicable
Facets.
All facets in
satisfy the constraints on facet components given in the appropriate subsection
of Constraining Facets.
The first case above will apply when a union is
constructed by specifying one or more member types, the second
when derived by restriction from another union.
Neither
D
nor any type
derived from it is a member of its
own transitive
membership.
A
simple type definition T is a
valid restriction of its
if and only if T satisfies constraint
.
Type Derivation OK (Simple)
The following constraint defines relations appealed to elsewhere in
this specification.
Type Derivation OK (Simple)
For a simple type definition (call it D, for
derived) to be validly derived from a type definition (call this
B, for base) subject to a set of blocking keywords
drawn from the set {extension,
restriction, list, union} (of which only
restriction is actually relevant; call this set S)
They are the same type definition.
restriction is not in S, or in
D..;
D.=B.
D. is not
xs:anyType and is validly derived from B
given S,
as defined by this constraint.
D.=list or union and B is xs:anySimpleType.
B.=union.
D is validly derived from a type definitionM in B's
transitive
membership given S, as defined by this
constraint.
The property of B
and of any intervening
union datatypes is empty.
It is a consequence of this requirement that the value space, lexical space, and
lexical
mapping of D will be subsets of those of
B.
With respect to , see the Note on identity at
the end of above.
When a simple type definition S is said to be
validly derived from a type definition T,
without mention of any specific set of blocking keywords,
then what is meant is that S is validly derived from
T, subject to the empty set of blocking keywords,
i.e. without any particular limitations.
It is a consequence of that
the constraint can hold between
a in the transitive membership of a union type, and the union type,
even though neither is actually derived from the other. The
slightly misleading terminology is retained for historical reasons
and for compatibility with version 1.0 of this specification.
Simple Type Restriction (Facets)
Simple Type Restriction (Facets)
For a simple type definition (call it R) to restrict another simple type
definition (call it B) with a
set of facets (call this S)
The of R is the same as that of B.
If is atomic, the
of R is the same as that of B.
The of Rare the of
Boverlaid
with S.
Additional constraint(s) sometimes apply depending on the kind of
facet, see the appropriate sub-section of 4.3 Constraining
Facets.
Given two sets of facets B and S,
the result of overlayingB with S is the set of facets R
for which
Every facet in S is in R.
Every facet in B is in R,
unless
it is of the same kind as some
facet in S,
in which case it is not included in R.
Every facet in R is required by
or above.
Built-in Simple Type Definitionsxs:anySimpleType
The of anySimpleType
is
present in every schema.
It has the following properties:
Simple Type Definition of anySimpleTypeanySimpleTypehttp://www.w3.org/2001/XMLSchemaThe empty setxs:anyTypeThe empty setThe empty setThe empty sequence
The definition
of xs:anySimpleType is the
root of the simple type definition
hierarchy, and as such mediates between the other simple type
definitions, which all eventually trace back to it via their
properties,
and
xs:anyType, which is
its.
xs:anyAtomicType
The of anyAtomicType
is present in every schema.
It has the following properties:
Simple Type Definition of anyAtomicType
anyAtomicTypehttp://www.w3.org/2001/XMLSchemaThe empty setxs:anySimpleTypeThe empty setThe empty setatomicThe empty sequencexs:error
A for xs:error is present in every schema
by definition. It has the following properties:
Simple Type Definition of xs:errorerrorhttp://www.w3.org/2001/XMLSchema{extension, restriction,
list, union}xs:anySimpleTypeThe empty setThe empty setunionThe empty sequenceThe empty sequence
The datatype xs:error has no valid instances
(i.e. it has an empty value space and an empty lexical space).
This is a natural consequence of its construction: a value is
a value of a union type if and only if it is a value of at
least one member of the of the union. Since xs:error has
no member type definitions, there can be no values which are
values of at least one of its member types. And since the value
space is empty, the lexical space is also empty.
The type xs:error is expected to be used
mostly in conditional type assignment. Whenever it serves as the
type definition for an attribute or element information
item, that item will be invalid.
Built-in primitive datatypes
Simple type definitions corresponding to all the built-in
primitive datatypes, namely string, boolean,
float, double, decimal, precisionDecimal,
dateTime, duration, time,
date, gMonth, gMonthDay,
gDay, gYear, gYearMonth,
hexBinary, base64Binary,
anyURI,
QName and NOTATION (see the
Primitive
Datatypes section of ) are present by
definition in
every schema
as follows:
corresponding to the built-in primitive datatypes
[as appropriate]http://www.w3.org/2001/XMLSchemaxs:anyAtomicTypeThe empty setatomic[this simple type
definition itself]{a facet with
value =
collapse and fixed = true in all cases except
string, which has
value =
preserve and fixed = false}
[as appropriate]
The empty sequence
All conforming implementations of this specification
must support all the primitive datatypes defined in .
It is implementation-defined whether additional primitive datatypes
are supported, and whether, if so, they are automatically
incorporated in every schema or not. If implementation-defined
primitives are supported, the implementation must
satisfy the rules for implementation-defined primitive datatypes
described in .
A type about which a processor possesses prior knowledge, and
which the processor can support without any declaration of the
type being supplied by the user, is said to be automatically known
to the processor.
By their nature, primitive types can be supported by a
processor only if automatically known to that processor.
Types automatically known to a processor, whether primitive or
derived, can be included automatically by that processor in
all schemas, but need not be. It is possible, for example,
for a processor to have built-in prior knowledge of a set of
primitive and derived types, but to include them in the schema
only when the relevant namespace is explicitly imported, or a
given run-time option is selected, or on some other
conditions; such conditions are not defined by this
specification.
The definition of automatically known is not
intended to prevent implementations from allowing users
to specify new primitive types.
If an implementation defines a mechanism by which users can
define or supply an implementation of a primitive type, then
when those mechanisms are successfully used, such user-supplied
types are automatically known to the implementation, as that term is
used in this specification.
Other built-in datatypes
Similarly, simple type definitions corresponding to all the other built-in datatypes (see the Other Built-in Datatypes section
of ) are present by definition in
every schema, with properties as specified in and as
represented in XML in Illustrative XML representations for the built-in ordinary type definitions.
corresponding to the ordinary built-in datatypes
[as appropriate]http://www.w3.org/2001/XMLSchema[as specified in the appropriate
sub-section of Other Built-in Datatypes]The empty set[atomic or list, as specified in the appropriate
sub-section of Other Built-in Datatypes][if is
atomic, then the of the , otherwise ][as specified in the appropriate
sub-section of Other Built-in Datatypes][as specified in the appropriate
sub-section of Other Built-in Datatypes]if is
atomic, then , otherwise as specified in the appropriate
sub-section of Other Built-in Datatypes]As shown in the XML representations
of the ordinary built-in datatypes in Illustrative XML representations for the built-in ordinary type definitions
All conforming implementations of this specification
must support all the built-in datatypes defined in .
It is implementation-defined whether additional derived types
are automatically known to the implementation without declaration
and whether, if so, they are automatically
incorporated in every schema or not.
The XML representation of the skeleton of a schema.
The Schema Itself
At the abstract level, the schema itself is just a container
for its components.
XML Representations of Schemas
A schema is represented in XML by one or more schema documents, that is, one or more element information items. A schema document contains representations for a collection of schema components, e.g. type definitions and element declarations, which have a common target namespace. A schema document which has one or more element information items corresponds to a schema with components with more than one target namespace, see .
The element information item
maps to a component as follows.
The simple and complex type definitions
corresponding to all the and element information items in the
children, if any, plus any
definitions brought in via
(see ),
(see ) and
(see ).The (top-level) attribute declarations
corresponding to all the element information items in the
children, if any, plus any
declarations brought in via
, and
.The (top-level) element declarations
corresponding to all the element information items in the
children, if any, plus any
declarations brought in via
, and
.The attribute group definitions
corresponding to all the element information items in the
children, if any, plus any
definitions brought in via
, and
.The model group definitions
corresponding to all the element information items in the
children, if any, plus any
definitions brought in via
, and
.The notation declarations
corresponding to all the element information items in the
children, if any, plus any
declarations brought in via
, and
.The identity-constraint definitions
corresponding to all the , and
element information items anywhere within the
children, if any, plus any
definitions brought in via
, and
.
The of the set of elements containing the
and all the ,
,
, and children, if any,
as defined in .
Note that none of the attribute information items displayed above
correspond directly to properties of schemas. The blockDefault,
finalDefault, attributeFormDefault, elementFormDefault and targetNamespace attributes are appealed to in the sub-sections above, as they provide
global information applicable to many representation/component correspondences. The
other attributes (id and version) are for user
convenience, and this specification defines no semantics for them.
The definition of the schema abstract data model in makes clear that most components have a target namespace. Most components corresponding to representations within a given element information item will have a target namespace which corresponds to the targetNamespace attribute.
Since the empty string is not a legal namespace name, supplying
an empty string for targetNamespace is incoherent, and is not the same
as not specifying it at all. The appropriate form of schema document
corresponding to a schema whose components have no
is one which has no
targetNamespace attribute specified at all.
discusses only instance document syntax for
elements and attributes; it therefore provides no direct framework for managing
the names of type definitions, attribute group definitions, and so on.
Nevertheless, the specification applies the target namespace facility uniformly to all
schema components, i.e. not only declarations but also definitions have a target namespace.
Although the example schema at the beginning of this section might be a complete XML document,
need not be the document element, but can appear within other documents.
Indeed there is no requirement that a schema correspond to a (text) document
at all: it could correspond to an element information item constructed 'by
hand', for instance via a DOM-conformant API.
Aside from and ,
which do not correspond directly to any schema component at all, each
of the element information items which may appear in the content
of
corresponds to a schema component, and all except are
named. The sections below present each such item in turn, setting out
the components to which it
corresponds.
References to Schema Components
Reference to schema components from a schema document is managed in
a uniform way, whether the component corresponds to an element
information item from the same schema document or is imported
() from an external schema
(which may, but need not, correspond to an actual schema
document). The form of all such references is a QName.
A QName is a
name with an optional namespace qualification, as defined in . When used in connection with the XML
representation of schema components or references to them, this refers
to the simple type QName
as defined in .
For brevity, the term
is also used to refer to actual values in the value space of the
QName simple type, which are
expanded names with a
local name
and a
namespace name.
An NCName is
a name with no colon, as defined in . When used in connection with the XML
representation of schema components in this specification, this refers
to the simple type NCName as defined in .
It is implementation-defined whether a
schema processor supports the definitions of QName and NCName found in or those found in or both.
A QName in a schema document
resolves to a component in a schema if and only if in the
context of that schema the QName and the component together satisfy the rule
. A QName in
an input document, or a pair consisting of a local name and a namespace name,
resolves to a component in a schema if and only if in the
context of that schema the QName (or the name + namespace pair) and the
component together satisfy the rule .
In each of the XML
representation expositions in the following sections, an attribute is shown as
having type QName if and only if it is
interpreted as referencing a schema component.
The first of these is most probably a local reference, i.e. a reference
to a type
definition corresponding to a element information item
located elsewhere in the schema document, the other two refer to type
definitions from schemas for other namespaces and assume that their namespaces
have been declared for import. See for a discussion of importing.
References to Schema Components from Elsewhere
The names of schema components such as type definitions and element
declarations are not of type ID: they are not
unique within a schema, just within a symbol space. This means that simple
fragment identifiers using these names
will not work to reference schema components from outside
the context of schema documents.
The preferred way to refer to schema components
is to use , which defines a mechanism to designate
schema components using the xscd()
scheme.
Alternatively, references to specific
element information items in the schema document can be interpreted as to their
corresponding schema documents. This can be done using mechanisms supported by
, for example, by using shorthand pointers.
It is a matter for applications to specify whether they interpret
these
references
as being to the relevant element information item (i.e. without
special recognition of the relation of schema documents to schema components) or as being to the
corresponding schema component.
Constraints on XML Representations of Schemas
None as such.
Validation Rules for Schemas as a Whole
None as such.
Schema Information Set Contributions
Schema Information
Schema Information
Schema components provide a wealth of information about the
basis of , which can often be useful for subsequent
processing. Reflecting component structure into a form suitable for
inclusion in the post-schema-validation infoset is the way this specification provides for
making this information available.
Accordingly, by an item isomorphic to a component is meant
an information item whose type is equivalent to the component's, with
one property per property of the component, with the same name, and
value either the same atomic value, or an information item
corresponding in the same way to its component value, recursively, as
necessary.
The
has the following properties:
A
set of namespace schema information information
items, one for each namespace name which appears as the target namespace of any schema component in the
schema used for that assessment, and one for absent if any schema component in the schema
had no target namespace. Each
namespace schema information information item has the
following properties and values:
A
namespace name or absent.A (possibly empty) set of schema component information
items, each one an item isomorphic to
a component whose target namespace is
the sibling property above, drawn from
the schema used for .A
(possibly empty) set of schema document information
items, with properties and values as follows, for each schema document
which contributed components to the schema, and whose
targetNamespace matches the sibling property above (or whose
targetNamespace was absent but that contributed components to
that namespace by being d by a schema document with that
targetNamespace as per
):
Either a URI reference, if available,
otherwise absentA document
information item, if available, otherwise absent.
The property is provided for
processors which wish to provide a single access point to the
components of the schema which was used during . Lightweight processors are free to leave it empty, but if it is provided, it must contain at a minimum all the top-level (i.e. named) components which actually figured in the , either directly or (because an anonymous component which figured is contained within) indirectly.
ID/IDREF Table
ID/IDREF Table
In the post-schema-validation infoset a set of ID/IDREF binding information items
is
associated with the :
A (possibly empty) set of
ID/IDREF binding information items, as specified below.
Let the
eligible item set be the set
consisting of every attribute or element
information item for which
its validation context is the
;
its schema actual value is
not absent and its type definition
is the built-in simple type definition for
ID,
IDREF, or
IDREFS,
or a simple type definition derived or constructed
directly (in a single derivation step) or
indirectly (through one or more steps) from any
of these;
if it is an element information item, then it is not .
The use of schema actual value
in the definition of above means that
default or fixed value constraints may play a
part in the .
Then there is one ID/IDREF binding in the
for every distinct string which is
the actual value of a member of the eligible
item set whose
type definition
or member type definition
is or is
derived
from ID or IDREF;
an item in the actual value of a member of the eligible
item set whose
type definition
or member type definition has
list and either its
or the item's
corresponding entry in member type definitions
is or is
derived from
ID or IDREF.
Each ID/IDREF binding has properties as follows:
The string identified above.A set consisting of every element information item for which
its is the
;
it has an attribute information item in
its attributes or an element information item in its childrenwhose actual value is or contains
the of
this ID/IDREF binding and the
corresponding type definition is or is derived from
ID.
The net effect of the above is to have one entry for every string used as an
id, whether by declaration or by reference, associated with those elements, if
any, which actually purport to have that id. See above
for the validation rule which actually checks for errors here.
The ID/IDREF binding
information item, unlike most other aspects of this
specification, is essentially an internal bookkeeping mechanism. It is introduced to
support the definition of above.
Constraints on Schemas as a Whole
Schema Properties Correct
All schemas (see ) must satisfy the following constraint.
Schema Properties Correct
The values of the properties of a schema are as described in
the property tableau in
, modulo the impact of ;
None of the
,
,
,
,
,, or
propertiescontains two or more schema components with the
same expanded name.
For a QName
to resolve to a schema component of a specified kind
That component is a member of the value of the appropriate
property of the schema which corresponds to the schema
document within which the QName
appears, that is
the kind specified is simple or complex type definition
the property is the .
the kind specified is attribute declaration
the property is the .
the kind specified is element declaration
the property is the .
the kind specified
is attribute group
the property is the .
the kind specified is
model group
the property is the .
the kind specified is notation declaration
the property is the .
the kind specified is identity-constraint
definition
the property is
the .
The
component's name matches the local
name of the QName;
The component's target namespace is identical to the namespace name of the QName;
the namespace name of the QName is absent
The element information item of the schema document containing the QName has no targetNamespaceattribute.
The element information item of the that schema document contains an element
information item with no namespaceattribute.
the namespace name of the QName is
the same as
The actual value of the targetNamespaceattribute of
the element information item of the schema document containing the QName.
The actual value of the namespaceattribute of some
element information item contained in the element information item of that schema document.
http://www.w3.org/2001/XMLSchema.
http://www.w3.org/2001/XMLSchema-instance.
QName resolution (Instance)
As the discussion above at makes clear,
at the level of schema components and validation,
reference to components by name is normally not involved. In a
few cases, however, qualified names appearing in information items being
validatedmust be resolved to schema
components by such lookup. The following
constraint is appealed to in these cases.
QName resolution (Instance)
A pair of a local name and a namespace name (or absent)
resolve to a schema component of a specified kind in the context of validation by appeal to the appropriate
property of the schema being used for the . Each such property indexes components by name. The property to use is determined by the kind of component specified, that is,
the kind specified is simple or complex type definition
the property is the .
the kind specified is attribute declaration
the property is the .
the kind specified is element declaration
the property is the .
the kind specified
is attribute group
the property is the .
the kind specified is
model group
the property is the .
the kind specified is notation declaration
the property is the .
The component resolved to is the entry in the table whose name matches the local name of the pair and whose target namespace is identical to the namespace name of the pair.
Schemas and Namespaces: Access and Composition
This chapter defines the mechanisms by which this specification establishes the necessary
precondition for , namely access to
one or more schemas. This chapter also sets out in detail the relationship
between schemas and namespaces, as well as mechanisms for
modularization of schemas, including provision for incorporating definitions
and declarations from one schema in another, possibly with modifications.
describes three levels of conformance for schema
processors, and provides a formal definition of
. This section sets out
in detail the 3-layer architecture implied by the three conformance levels.
The layers
are:
The core, relating schema components and instance
information items;
Schema representation: the connections between XML
representations and schema components, including the
relationships between namespaces and schema components;
XSD web-interoperability guidelines:
connections
from instance to schema (or schema document) and from schema document
to schema (or schema document) for the WWW.
Layer 1 specifies the manner in which a schema composed of schema components
can be applied to in the of an
element information item. Layer 2 specifies the use of
elements in XML documents as the standard XML representation for
schema information in a broad range of computer systems and execution
environments. To support interoperation over the World Wide Web in particular,
layer 3 provides a set of conventions for schema reference on the
Web. Additional details on each of the three layers
are
provided in the sections below.
Layer 1: Summary of the Schema-validity Assessment Core
The fundamental purpose of the core is to define for a single
element information item and its descendants,
with respect to a
complex type
definition. All processors are required to implement this core predicate in a
manner which conforms exactly to this specification.
Assessment is defined with reference to
an XSD schema (note not a
schema document).
As specified above, each schema component is associated directly or
indirectly with a target namespace, or explicitly with no namespace. In the case of multi-namespace documents,
components for more than one target namespace will co-exist in a schema.
Processors have the option to assemble (and perhaps to optimize or
pre-compile) the entire schema prior to the start of an
episode, or to
gather the schema lazily as individual components are required. In all
cases it is required that:
The processor succeed in locating the schema components
transitively required to complete an (note that components derived
from schema documents can be integrated
with components obtained through other means);
no definition or declaration changes once it has been established;
if the processor chooses to acquire declarations and definitions
dynamically, that there be no side effects of such dynamic acquisition that
would cause the results of to differ from that which would have
been obtained from the same schema components acquired in bulk.
the core is defined in terms of schema components at the
abstract level, and no mention is made of the schema definition
syntax (i.e. ). Although many processors will acquire
schemas in this format, others may operate on compiled representations, on a
programmatic representation as exposed in some programming language, etc.
The obligation of a schema-aware processor as far as the
core is concerned is to implement one or more of the options for given below in . Neither the
choice of element information item for that , nor which of the
means of initiating are used, is within the scope of this specification.
Although is defined recursively, it is also intended to be
implementable in streaming
processors. Such processors may choose to incrementally assemble the schema during
processing in response, for example, to encountering new namespaces.
The implication of the
invariants expressed above is that such incremental assembly must
result in an
outcome that is the
same as would
be given if were
undertaken again
with the final, fully assembled schema.
Layer 2: Schema Documents, Namespaces and Composition
The sub-sections of define an
XML representation for type definitions and element declarations and so on,
specifying their target namespace and collecting them into schema documents.
The following sections describe how to
assemble a complete schema from multiple sources.
The core
architecture requires that a complete schema with all the necessary
declarations and definitions be available.
This will
sometimes involve resolving both instance → schema
(or schema document)
and schema-document → schema
(or schema document) references.
As observed earlier in , the
precise mechanisms for resolving such references are expected to
evolve over time. In support of such evolution, this specification
observes the design principle that references from one schema document
to a schema use mechanisms that directly parallel those used to
reference a schema from an instance document.
In the sections below, "schemaLocation" really belongs at layer 3.
For convenience, it is documented with the layer 2 mechanisms of import and
include, with which it is closely associated.
Basic concepts of schema construction and composition
When a schema is assembled from multiple sources, those sources
can include both schema documents and other sources of
components. Several of the mechanisms described below
allow a schema document to refer to a schema, either
by giving the target namespace of its components,
or indirectly, by referring to a schema document (and
thus implicitly to the schema corresponding to that schema document).
The sections that follow appeal often to the following
concepts.
The pre-processing of a schema document before
attempting to map its contents into components,
or the pre-processing of a set of components
before they take their final form among the
components of a schema being constructed.
The following sections define several forms of
pre-processing, including:
conditional-inclusion pre-processing,
chameleon pre-processing,
redefinition pre-processing,
and
override pre-processing.
Conditional-inclusion pre-processing is always performed first;
the sequence in which other forms of pre-processing
are applied varies; details are given below.
The process of applying to a schema document the
filtering described in section .
This pre-processing is usually assumed silently; when
it is explicitly described, then
for a schema documentD, the result of conditional-inclusion
pre-processing of D is written ci(D).
The immediate components of a schema documentD
are the components corresponding to its definition and
declaration children; also written
immed(D).
The
,
,
, and
elements defined below.
The schema corresponding to a given schema documentD
is the schema containing the built-in components,
the automatically known components automatically included
in the schema by the schema processor,
immed(D),
and the
components included by virtue of the inter-schema-document
references included in D (for which see the rules below),
and no other coponents.
Also written
schema(D).
The target namespace specified in a schema document D;
also written
tns(D).
The application, to a schema document D, of the
transformation specified in ,
with respect to some namespace N, so as to convert
it to use N as its target namespace;
also written
chameleon(N,D).
The application, to a schema document D, of the
overrides specified in an
element E, using the rules specified in detail
in ;
also written
override(E,D).
The application, to a schema S, of the
redefinitions specified in an
element E, using the rules specified in detail
in ;
also written
redefine(E,S).
This specification defines several attributes to allow
schema documents and XML instance documents to provide
information about the location of relevant schema components.
Experience has shown that the similarities and differences
among these attributes can be elusive for some readers; a
compact overview may be helpful.
The xsi:schemaLocation and
xsi:noNamespaceSchemaLocation attributes
may validly appear on elements in an XML instance
document. They are technically hints:
conforming schema-aware processors may but need not
attempt to dereference the schema documents named
in these attributes and include the components described
there in the schema used for validation.
The schemaLocation attribute on the
element in a schema document is
similarly a hint: a conformaing schema-aware
processor may but need not attempt to dereference
the schema document named by the attribute.
The schemaLocation attributes on the
, , and
elements in a schema document, on the
other hand, are not hints: conforming processors must attempt
to de-reference the schema document named by the attribute.
For non-empty elements, it is
an error for the attempt to fail; otherwise, the
attempt must be made but it is not an error for it
to fail.
In all cases, the use of the attribute in a document
indicates
the existence of a suitable schema document
at the location indicated. This is stated explicitly
below for some attributes, but not for all; where not
stated explicitly, the inference follows implicitly
from other rules.
Conditional inclusion
Whenever a conforming XSD processor reads a
schema document in order to include the components defined
in it in a schema, it first performs on the schema document
the pre-processing described in this section.
Every element in the schema document is examined to
see whether any of
the attributes vc:minVersion,vc:maxVersion,
vc:typeAvailable,
vc:typeUnavailable,
vc:facetAvailable, or
vc:facetUnavailable
appear among its attributes.
Where they appear, the
attributes vc:minVersion
and vc:maxVersion are treated as if declared
with type xs:decimal, and their actual values are compared to a decimal
value representing the version of XSD supported by the
processor (here represented as a variable V). For processors
conforming to this version of this specification, the value of
V is 1.1.
If V is less than the value of
vc:minVersion, or
if V is greater than or equal to the value of
vc:maxVersion,
then the element on which the attribute appears is
to be ignored, along with all its
attributes and
descendants.
The effect is that portions of the
schema document marked with vc:minVersion and/or
vc:maxVersion are retained if
vc:minVersion ≤ V < vc:maxVersion.
Where they appear, the attributes vc:typeAvailable
and vc:typeUnavailable are treated as if declared
with type list of xs:QName, and the items in their
actual values are checked to see whether they name types
automatically known to the processor. The attributes
vc:facetAvailable and vc:facetUnavailable
are similarly typed, and checked to see if they name facets
supported by the processor.
If an element in a schema document has any of the following:
vc:typeAvailable = T, where any item in the
actual valueT is not the expanded name of some type definition automatically known to the
processor
vc:typeUnavailable = T, where
every item in the
actual valueT is the expanded name of some type
definition automatically known to and supported by the processor
vc:facetAvailable = F, where any item in the
actual valueF is not the expanded name of some facet
known to and supported by the processor
vc:facetUnavailable = F, where
every item in the
actual valueF is the expanded name of some facet known to and supported
by the processor
then the element on which the attribute appears is to be
ignored, along with all its attributes and descendants.
It is expected that vc:typeAvailable etc. will be
most useful in testing for implementation-defined primitive datatypes
and facets, or for derived types for which the processor
supplies a definition automatically. The rules just given do
not, however, attempt to restrict their use to such tests. If
the vc:typeAvailable attribute is used with the
expanded name
associated with one of the built-in primitive datatypes, the
datatype will (in a conforming processor) always be available,
so the test is unlikely to filter out any elements, ever, from
the schema document. But such a usage is not in itself an
error.
The expanded names of the built-in datatypes are as specified
in ; the expanded name of any implementation-defined datatype
is required by to be specified by the implementation.
The expanded names of the facets (built-in or implementation-defined)
are the expanded names of the elements used in XSD schema documents
to apply the facets, e.g. xs:pattern for the pattern
facet.
It is a consequence of the rules given above that
if the actual value of vc:typeAvailable is the empty list
(i.e. vc:typeAvailable=""), then the corresponding element
is not ignored. (It does not list any type that is
not available.) Conversely, if the actual value of
vc:typeUnavailable is the empty list, then the corresponding
element is ignored. Similar results hold for
vc:facetAvailable and vc:facetUnavailable.
The pre-processing of a schema document S1 results
in a second schema document S2, identical to S1
except that all elements and
attributes in S1 which are to be ignored
are absent from S2.
We write S2 = ci(S1).If the <schema>
element information item in S1 is to be ignored, then S2 is identical
to S1 except that any attributes other than targetNamespace,
vc:minVersion or vc:maxVersion are removed from its
attributes, and its children is the empty sequence.
It is S2, not S1, which
is required to conform to this specification.
If S1 contains no elements
or attributes to be ignored, then S1 and
S2 are identical.
Except where conditional-inclusion pre-processing is
explicitly mentioned, references to schema documents
elsewhere in this specification invariably refer to
the result of the pre-processing step described here,
not to its input, which need not, and in the general
case will not, always conform to the rules for
schema documents laid out in this specification.
Suppose some future version of XSD (say, version 3.2)
introduces a new form of element declaration. A schema author
might wish to exploit that new form of declaration if
possible, but wish also to ensure that the schema
document can be handled successfully by a processor
written for XSD 1.1. In such a case, a schema document
of the following form would be handled correctly by a
conforming XSD 1.1 processor:
<xs:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:vc="http://www.w3.org/2007/XMLSchema-versioning">
<xs:element name="e" vc:minVersion="3.2">
<!--* declaration suitable for 3.2
* and later processors *-->
</xs:element>
<xs:element name="e"
vc:minVersion="1.1"
vc:maxVersion="3.2">
<!--* declaration suitable for processors
* supporting versions 1.1 through versions
* up to (but not including) 3.2
*-->
</xs:element>
...
</xs:schema>
Even though the schema document as shown has two element
declarations for element e and thus
violates of constraint
, the pre-processing step
described in this section filters out the first element
declaration, making it possible for the resulting schema
document to be valid and to conform to this specification.
Note that the semantics of the vc:maxVersion attribute is
"exclusive". This makes it easier for schema authors to use this feature
without leaving gaps
in the numeric ranges used to select version numbers.
Suppose that a processor supports an implementation-defined primitive
named xpath_expression in namespace
http://example.org/extension_types,
and is presented with the following schema document:
The effect of conditional inclusion is to include the
first declaration for e and omit the second, so
that the effective schema document, after pre-processing
for conditional inclusion, is:
Whenever the attribute vc:minVersion or
vc:maxVersion appears on an element information item in a
schema document, its initial valuemust
be locally valid
with respect to xs:decimal as per
.
Whenever any of the attributes
vc:typeAvailable,
vc:typeUnavailable,
vc:facetAvailable, or
vc:facetUnavailable,
appears on an element information item in a
schema document, its initial valuemust
be locally valid
with respect to a simple type definition with
= list
and
=
xs:QName, as per
.
Any attribute from the vc: namespace that appears
on an element information item in a
schema documentshould be one of the attributes described
elsewhere in this document (i.e. one of
vc:minVersion, vc:maxVersion, vc:typeAvailable,
vc:typeUnavailable, vc:facetAvailable, or
vc:facetUnavailable).
Processors are encouraged to issue warnings about
vc: attributes other than those named,
but it is not an error for such
attributes to appear in a schema document. The rule just
given is formulated with a should and not
a must in order to preserve the ability of
future versions of this specification to add new attributes
to the schema-versioning namespace.
Assembling a schema for a single target namespace from
multiple schema definition documents
(<include>)
Schema components for a single target namespace can be
assembled from several schema documents, that is several
element information items:
A information item may contain any
number of elements. Their
schemaLocation attributes, consisting of a URI reference,
identify other schema documents, that is information items.
If two elements
specify the same schema location (after resolving
relative URI references) then they refer to the same schema document. If
they specify different schema locations, then they refer to different schema
documents, unless the implementation is able to determine that the two URIs
are references to the same resource.
If a schema documentD1
contains one or more elements,
then schema(D1) contains not only
immed(D1) but also all the components
of schema(D2), for each schema documentD2 identified by an element
child of D1.
Such included schema
documents D2must either (a) have the same
targetNamespace as D1,
or (b) no targetNamespace at all,
in which case the
components included in schema(D1) are
not those of schema(D2) itself, but instead
those of schema(chameleon(tns(D1),D2)),
that is, the schema corresponding to the result of applying
chameleon pre-processing to D2 to convert it to
target namespace tns(D1).
Inclusion Constraints and Semantics
In addition to the conditions imposed on element
information items by the schema for schema documents,
If the actual value of the schemaLocationattribute successfully resolves
It resolves to (a fragment of) a resource which is an
XML document (of type application/xml or
text/xml with an XML declaration for
preference, but this is not required), which in turn
corresponds to a element
information item in a well-formed information set.
It resolves to a element
information item in a well-formed information set.
In either case call the d
item D2 and the
ing item's parent item D1.
D2 has a targetNamespaceattribute, and its actual value is identical to the
actual value of the targetNamespaceattribute of D1 (which must have such an
attribute).
Neither D2 nor D1 have a
targetNamespaceattribute.
D2 has no
targetNamespaceattribute (but D1
does).
D2 does not exist (e.g. because the actual value of the
schemaLocationattribute does not
resolve successfully).
or above is satisfied
D2 corresponds to a conforming schema (call it S2).
The schema corresponding to D1 includes not only definitions or
declarations corresponding to the appropriate members of its own
children, but also components identical to all the
schema components of
S2 (with the possible
exception of its component).
above is
satisfied
Let D2′ be a information item
obtained by performing on D2 the transformation
specified in ;D2′ corresponds to a conforming schema (call it S2).
The transformation in
(a) adds a targetNamespaceattribute to D2,
whose value is the same as that of the targetNamespaceattribute of D1, and (b) updates all unqualified
QName references so that their namespace names become the
actual value of the targetNamespaceattribute.
Implementations need not use the
stylesheet given in ,
as long as an equivalent result
is produced.
In particular, different
algorithms for generating a unique namespace
prefix may be used, even if they produce different
results.
The schema corresponding to D1 includes not only definitions or
declarations corresponding to the appropriate members of its own
children, but also components identical to all the
schema components of S2 (with the possible
exception of its component).
The above rule applies recursively. For example, if
A includes B and
B includes C, where
A has a targetNamespaceattribute, but neither B nor
C does, then the effect is as if
A included B' and
B' included C', where
B' and C' are identical to
B and C respectively,
except that they both have a
targetNamespaceattribute the same as
A's.
In this case, it is D2′, not D2, which is required
by to correspond to a conforming schema.
In particular, it is not an error for D2 to
fail to satisfy
all of the constraints governing schema documents, while
it is an error if D2′ fails to satisfy them.
If D2 imports the target namespace of D1, then
the effect of will be to
cause an error owing to the violation of of (which forbids a schema document to
import its own target namespace). Other constraint
violations may also be brought about; caution is
advised.
It is not an error for the actual value of the
schemaLocationattribute to fail to resolve
at all,
in which case the corresponding inclusion must not be performed. It
is an error for it to resolve but the rest of clause 1
above to fail to be satisfied. Failure to resolve is likely
to cause less than complete outcomes, of course.
As discussed in , QNames in XML representations will
sometimes fail to resolve, rendering components incomplete
and unusable because of missing subcomponents. During schema
construction, implementations must retain QName values for such references, in case
an appropriately-named component becomes available to discharge the
reference by the time it is actually needed. Absent target namespace
names of such as-yet unresolved reference QNames in d
components must also be converted if is
satisfied.
The above is carefully worded so that
multiple ing of the same schema document will not
constitute a violation of
of , but
applications are allowed, indeed encouraged, to avoid ing the
same schema document more than once to forestall the necessity
of establishing identity component by component.
If there is a sequence of schema documents S1, S2, ... Sn,
and a sequence of elements E1, E2, ... En,
such that each Si contains the corresponding Ei, and each Ei(where i < n)
points to
schema document Si + 1, and
En points to S1 (i.e. if there is a cycle in the relation defined by the
element), then the same schema corresponds to all
of the schema documents S1, ... Sn in the cycle, and it includes the same
components as the schema corresponding
to S1 in the similar case whereSn has no
element pointing at S1.
Informally:
cycles of elements are legal, and
processors should guard against infinite loops.
Including modified component definitions (<redefine>)
The redefinition feature described in the remainder of this
section is deprecated and may be removed from future versions of
this specification. Schema authors are encouraged to avoid its
use in cases where interoperability or compatibility with later
versions of this specification are important.
The Working Group requests feedback from readers, schema
authors, implementors, and other users of this specification as
to the desirability of retaining, removing, deprecating, or not
deprecating the use of . Since the
facility provides similar
functionality but does not require a restriction or extension
relation between the new and the old definitions of redefined
components, the Working Group is particularly interested in
learning whether users of this specification find that
requirement useful or not.
In order to provide some support for evolution and versioning, it is
possible to incorporate components corresponding to a schema document
with modifications. The modifications have a pervasive impact,
that is, only the redefined components are used, even when referenced from
other incorporated components, whether redefined themselves or not.
A information item may contain any number of elements. Their schemaLocation attributes, consisting of a URI reference, identify other schema documents, that is information items.
If a schema document D1
contains a element E
pointing to some schema document D2, then
schema(D1) contains not only the components in immed(D1), but also
all the components (with the exception, in most cases,
of the schema-as-a-whole component) of
redefine(E,schema(D2)).
For any document D2 pointed at by a element
in D1, it must be the case either (a) that tns(D1) = tns(D2)
or else (b) that tns(D2) is absent, in which case schema(D1) includes not
redefine(E,schema(D2)) itself
but redefine(E,schema(chameleon(tns(D1),D2))).
That is, the redefinition pre-processing is applied not to the
schema corresponding to D2 but instead to the schema corresponding
to the schema document chameleon(tns(D1),D2),
which is the result of applying chameleon pre-processing to D2
to convert it to target namespace tns(D1).
The definitions within the element itself are
restricted to be redefinitions of components from the d
schema document, in terms of themselves. That is,
Type
definitions must use themselves as their base type definition;
Attribute
group definitions and model group definitions must be supersets or subsets of their original
definitions, either by including exactly one
reference to themselves or by containing only (possibly restricted) components
which appear in a corresponding way in their d selves.
Not all the components of the d
schema document need be redefined.
This mechanism is intended to provide a declarative and modular approach to
schema modification, with functionality no different except in scope from what
would be achieved by wholesale text copying and redefinition by editing. In
particular redefining a type is not guaranteed to be side-effect free: it can
have unexpected impacts on other type definitions which are based
on the redefined one, even to the extent that some such definitions become
ill-formed.
The pervasive impact of redefinition reinforces the need for
implementations to adopt some form of lazy or 'just-in-time' approach to
component construction, which is also called for in order to avoid
inappropriate dependencies on the order in which definitions and references appear in (collections of) schema documents.
The schema corresponding to v2.xsd has everything specified
by v1.xsd, with the personName type redefined, as
well as everything it specifies itself. According to
this schema, elements constrained
by the personName type may end with a generation
element. This includes not only the author element, but also the
addressee element.
Redefinition Constraints and Semantics
In addition to the conditions imposed on element information items by the schema for schema documents
If there are any element information items among the
children other than then the
actual value
of the schemaLocationattributemust
successfully resolve.
If the actual value of the schemaLocationattribute successfully resolves
it resolves to (a fragment of) a resource which is an
XML document (see of ), which in turn
corresponds to a element
information item in a well-formed information set.
It resolves to a element
information item in a well-formed information set.
In either case call the d
item D2 and the
ing item's parent
item D1.
D2 has a targetNamespaceattribute, and its actual value is identical to the
actual value of the targetNamespaceattribute of D1 (which must have such an
attribute).
Neither D2 nor D1 have a
targetNamespaceattribute.
D2 has no
targetNamespaceattribute (but D1
does).
or above is satisfied
D2 corresponds to a conforming schema (call it S2).
The schema corresponding to D1 includes not only definitions or
declarations corresponding to the appropriate members of its own
children, but also components identical to all the
schema components of S2, with the
exception of those explicitly redefined
(see below
and with the possible
exception of the component
of S2)).
above is
satisfied
Let D2′ be a information item
obtained by performing on D2 the transformation
specified in ;D2′ corresponds to a conforming schema (call it S2).
The schema corresponding to D1 includes not only definitions or
declarations corresponding to the appropriate members of its own
children, but also components identical to all the
schema components of S2, with the
exception of those explicitly redefined
(see below).
In this case, it is D2′ and not D2, which is required
by to correspond to a conforming schema.
In particular, it is not an error for D2 to
fail to satisfy
all of the constraints governing schema documents, while
it is an error if D2′ fails to satisfy them.
Within the children, each must have a among its
children and
each must have a
restriction or extension among its
grand-children the actual value of whose baseattributemust be the same as the actual value of its own
name attribute plus target namespace;
Within the children, for each
it has a among its
contents at some level the actual value of whose
refattribute is the same as the
actual value of its own name attribute plus
target namespace
and that does not have an
ancestor
It has exactly one such group.
The actual value of both that group's
minOccurs and maxOccursattributeis1 (or absent).
it has no such self-reference
The actual value of its own name attribute
plus target namespace successfully resolves to a
model group definition in S2.
The of the
model group definition which corresponds to it per
accepts a subset of the element
sequences accepted by that model group definition in
S2.
Within the children, for each
it has an
among its contents the actual value of whose
refattribute is the same as the
actual value of its own name attribute plus
target namespace
it has exactly one such group.
it has no such self-reference
The actual value of its own name attribute
plus target namespace successfully resolves to an
attribute group definition in S2.
The and
of the attribute group
definition which corresponds to it per viewed as the and of a and the and of that attribute group
definition in S2 viewed as the and of the
satisfy of .
An attribute group restrictively redefined per
corresponds to an attribute
group whose
consist all and only of those attribute uses corresponding
to s explicitly present among
the children of the ing
. No inheritance from the
d attribute group occurs. Its
is
similarly based purely on an explicit , if present.
Individual Component Redefinition
Corresponding to each non- member of the
children of a there are one or two schema components in
the ing schema:
The and children information items each
correspond to two components:
One component which corresponds to the top-level definition item with
the same name in
the d schema document, as defined in , except that its name is absent and its context is the redefining component, as defined in below;
One component which corresponds to the information item itself, as defined
in , except that its base type definition is
the component defined in above.
This pairing ensures the coherence constraints on type definitions
are respected, while at the same time achieving the desired effect, namely that
references to names of redefined components in both the ing and
d schema documents resolve to the redefined component
as specified in 1.2 above.
The and children each correspond to a single component, as defined in , except that if and when a self-reference based on a refattribute whose actual value is the same as the item's name plus target namespace is
resolved, a component which corresponds to the top-level definition item of that name and the appropriate kind in
S2 is used.
In all cases there must be a top-level definition item of the appropriate name and kind in
the d schema document.
The above is carefully worded so that
multiple equivalent ing of the same schema document will not constitute a violation of
of , but applications are
allowed, indeed encouraged, to avoid ing the same
schema document in the same way more than once to forestall the necessity of
establishing identity component by component (although this will have to be
done for the individual redefinitions themselves).
Overriding component definitions (<override>)
The <redefine> construct defined
in
is useful in schema evolution and versioning,
when it is desirable to have some guaranteed restriction or extension
relation between the old component and the redefined component.
But there are occasions when the schema author simply wants to
replace old components with new ones without any constraint.
Also, existing XSD processors
have implemented conflicting and non-interoperable interpretations
of , and the
construct is deprecated.
The construct defined in this section
allows such unconstrained replacement.
The name of the element
has nothing to do with the use of the term
to denote the relation between an
and another type. The two mechanisms are
distinct and unrelated.
A information item may contain any number of
elements. Their schemaLocation
attributes, consisting of a URI reference, identify
(point to)
other schema documents,
that is information items.
If a schema document Dnew
contains an element E
pointing to some schema document Dold, then
schema(Dnew) contains not only the components in immed(Dnew),
but also the components in
schema(override(E,Dold)).
For all such schema documents Dold,
it must be the case either (a) that tns(Dold) = tns(Dnew),
or (b) that tns(Dold) is absent, in which case
schema(Dnew) contains not the components in
schema(override(E,Dold)), but those in
schema(override(E,chameleon(tns(Dnew),Dold))).
That is, before the override pre-processsing is applied,
chameleon pre-processing is applied to Dold to convert it
to target namespace tns(Dnew); the override
pre-processing is applied to the result, namely
chameleon(tns(Dnew),Dold).
Several alternative formattings are possible for the new
variable names here. Which is preferable?
(a) Dnew and Dold, or
(b) D_new and D_old, or
(c) D_new and D_old, or
(d) D-new and D-old, or
(e) Dnew and Dold?
The children of the
elementmay override any source declarations for
named components which
appear among the children of the
,
, or
elements in the of
the element information item..
The
target set of an element information
item E contains
The schema document identified by the schemaLocation
attribute of E.
The schema document identified by the schemaLocation
attribute of any element information item
in a schema document contained in the
of E.
The schema document identified by the schemaLocation
attribute of any element information item
in a schema document contained in the
of E.
The target set of E contains no other schema documents.
The of an element is
the transitive closure of the union of the inclusion relation (which contains
the pair (S1, S2) if and only if S1 contains an
element pointing to S2) and the override relation (which contains
the pair (S1, S2) if and only if S1 contains an
element pointing to S2). It does not include schema documents which
are pointed to by or elements,
unless they are also pointed to by or
elements in the relevant schema documents.
Source declarations not present in the target set of E cannot
be overridden, even if they are present in other schema
documents consulted in the creation of the schema (e.g. in
schema documents pointed to by a
element).
It is not forbidden for the schema document D containing
an element E to be in the
of E.
If applying the override transformation specified in
to D and E results in
a schema document equivalent to D (e.g. when none of the children
of D, or of any and
elements in D match any of the children of E, except
for the children of E themselves), then the effect is the same
as for a cyclic set of references, or
as for multiple inclusions of the same document (as
described in the note at the end of
).
If applying the override transformation to D and E changes
any of the XML representations of components, then the effect of
D being in the of E is the same
as if two different schema documents containing conflicting
definitions for the same components were included. (As if
is inexact; in this case what happens is, precisely,
that two schema documents with conflicting contents are
included.)
The definitions within the element itself are
not required to be similar in any way to
the
source declarations being
overridden. Not all the source declarations
of the overridden schema document need be
overridden.
As this mechanism is very similar to , many similar
kinds of caution need to be taken in using . Please
refer to for details.
The schema corresponding to v1.xsd has a complex type named
personName with a sequence of firstName
and lastName children. The schema corresponding to v2.xsd
overrides personName, by providing a different sequence of
element children. All elements with the personName type are
now constrained to have the sequence of givenName and
surname. This includes not only the author
element, but also the addressee element.
Override Constraints and Semantics
In addition to the conditions imposed on element
information items by the schema for schema documents
If the actual value of the schemaLocationattribute
successfully resolves
It resolves to (a fragment of) a resource which is an XML document (see
of ), which in turn
corresponds to a element information item in a
well-formed information set.
It resolves to a element information item in a
well-formed information set.
In either case call the overridden item Dold
and the overriding item's parent item Dnew.
Dold has a targetNamespaceattribute, and its
actual value is identical to the actual value of the targetNamespaceattribute of Dnew (which must have such an attribute).
Neither Dold nor Dnew have a targetNamespaceattribute.
Dold has no targetNamespaceattribute (but Dnew
does).
or
above is satisfied
Let Dold′ be a information item obtained by
performing on Dold the transformation
specified in . Then
Dold′ corresponds to a conforming schema (call it Sold).
The element in schema document Dnew
pointing to Dold is replaced by an
element pointing to Dold′
and the inclusion is handled as described in
.
It is not necessary to perform a literal replacement
of the element in Dnew with an
element; any implementation technique
can be used as long as it produces the required result.
One effect of the rule just given is that
the schema corresponding to Dnew includes not only definitions or
declarations corresponding to the appropriate members of its own
children, but also components identical to all the
schema components of Sold
(with the possible
exception of the component
of Sold).
Another effect is that if schema document A contains
a source declaration for a component E, and schema document B
overrides A with its own declaration for E,
and schema document C in turn overrides B with a
third declaration for E, then
First, the override of B by C is handled. The
resulting schema document still contains an
element referring to C,
but the declaration for E contained in it has
been replaced by that specified in C.
Then, the override of A by (the modified version of) B
is handled.
The resulting version of A, containing
the declaration for E originally present in C,
is included by the modified version of B,
which is itself included by C.
The resulting schema contains
the version of E originally specified in
schema document C.
(The references to first and
next here refer to the logical precedence
of operations, not to a required order in which implementations
are required to perform particular tasks.)
above is satisfied
Let Dold′ be a information item obtained by
performing on Dold first the transformation
specified in and then the
transformation specified in . Then
Dold′ corresponds to a conforming schema (call it S2).
The element in schema document Dnew
pointing to Dold is replaced by an
element pointing to Dold′
and the inclusion is handled as described in
.
The effect of applying the stylesheet in
is to make Dold′ identical to Dold except that some elements in
Dold are replaced
or modified, as described in
.
Implementations do not have to use
transformation, as long as the same result is produced.
It is Dold′ and not Dold, which is required to correspond to a
conforming schema. In particular, it is not an error for Dold to fail to
satisfy all of the constraints governing schema documents, while it
is an error if Dold′ fails to satisfy them.
In , components are allowed or required to refer to
themselves. There is no similar special treatment in .
Overriding components are constructed as if the overridden components had never
existed.
The above is carefully worded so that
multiple equivalent overrides of the
same schema document will not constitute a violation of
of , but applications are allowed, indeed
encouraged, to avoid overriding the same schema document in the same way
more than once to forestall the necessity of establishing identity component
by component.
It is a consequence of the semantics of inclusion, as
defined in (in particular
and
);
redefinition, as defined in
;
import, as defined in
;
and overriding, as defined in this section,
that if the same schema document is both (a) included, imported, or
redefined, and (b) non-vacuously overridden, or if the same
schema document overridden twice in
different ways, then
the resulting schema will have duplicate and conflicting versions
of some components and will not be conforming,
just as if two different schema documents had been
included, with different declarations for the same
named components.
References to schema components across namespaces (<import>)
As described in , every top-level schema component is associated with
a target namespace (or, explicitly, with none). Furthermore,
each schema document carries on its element
at most one targetNamespace attribute associating that document
with a target namespace. This section sets out
the
syntax and mechanisms by which references
may be made from within a schema document to components
outside that document's target
namespace. Also included within the same syntax is an optional
facility for suggesting the URI of a
schema document containing
definitions and declarations for components from the foreign
target namespace.
Some users of version 1.0 of this specification have mistakenly
assumed that the
primary purpose of the is to cause retrieval of
a resource identified by the schemaLocation attribute.
Although the function of is
unchanged in this version, the presentation below has been
reorganized to clarify the two separate purposes served by
, namely
(1) to license references, within a schema document, to
components in the imported namespace, and (2) to provide information
about the location of schema documents for imported namespaces.
The element information item identifies namespaces
used in external references, i.e. those whose
QName identifies them as coming from a
different namespace (or none) than the enclosing schema document's
targetNamespace.
Licensing References to Components Across Namespaces
At least two conditions must be satisfied for a
reference to be made to a foreign component: (1)
there must be a
means of addressing such foreign components,and
(2) there must be a signal to
schema-aware processors that a schema document contains such
references. The namespace
mechanisms defined by
satisfy the first requirement by allowing foreign components
to be addressed.
(How those components are located is governed by the
processor's strategies for locating schema components
in a given namespace, in which the schemaLocation attribute
on the element can play a role;
see also .)
The element information item
serves
to satisfy the second requirement, by identifying
namespaces used in external component
references, i.e. those whose
QName identifies them as coming
from a namespace different from that of the enclosing schema
document's targetNamespace.
By contrast, a namespace used for other purposes in a schema document
need not be imported.
There is
no need, for example, to import the
namespace of a vocabulary such as XHTML
for use in schema
elements, unless that same namespace is also
used as the target namespace for component references.
If the schema document does refer to components in the XHTML
namespace, then the schema document must include an element of the form
<xs:import namespace="http://www.w3.org/1999/xhtml"/>
(with the possible addtion of a schemaLocation attribute
and annotations). As just described, this explicit import
makes it legitimate to refer to components in the XHTML namespace,
as base type definitions, or from within content models.
No import is needed in order to use XHTML to mark up the text
appearing within elements, since
that usage does not require the schema being constructed to
include components from the XHTML namespace. (As a
practical matter, this saves the processor the effort to
locate a schema for the XHTML namespace.) Importing or
not importing the XHTML namespace in a schema document
has no effect on the validity of XHTML within
elements: elements in the XHTML
namespace (or any other namesapce) are allowed within
or
element in the schema document, because the schema for
schema documents in
declares the type of those elements with a lax wildcard.
Also, importing the namespace affects the schema being
constructed, not the schema used to validate schema
documents. The latter is specified in .
Different designs for namespace import could of course be
imagined. In particular, declaring a prefix for a namespace could
automatically import that namespace.
If each use of a foreign namespace within a schema document
implicitly imported that namespace into the schema being
constructed, then using XHTML for documentation would automatically
result in the inclusion of XHTML components in the schema
described by the schema document. The same logic would also
apply to any vocabulary used for documentation. Such automatic import
would lead processors to expend unnecessary extra effort
to find components for the documentation namespace and would in many
cases result in a schema which is not the one intended or desired
by the schema author.
Additionally, the requirement that the
element be used explicitly provides a modest level of
redundancy that makes it easier to detect some kinds of errors
in the schema document.
The actual value of
thenamespaceattribute indicates that the containing schema document may contain
qualified references to schema components in that namespace (via one or more
prefixes declared with namespace declarations in the normal way). If that
attribute is absent, then the import allows unqualified reference to components
with no target namespace.
It is a consequence of rules defined elsewhere
that if references to components in a given namespace N
appear in a schema document S,
then Smust contain an element
importing N.
Otherwise, the references will fail to resolve; see
of
.
References in a schema document to foreign namespaces not imported
by that schema document (or otherwise accounted for by
) are notforward references in the sense of
and are not
handled as if they referred to
missing components in the sense of
.
Note that components to be imported need not be in the form of a
schema document and
need not in particular be declared in the particular schema document identified
by a schemaLocation attribute; the processor
is free to access or construct components using means of its own
choosing, whether or not a schemaLocation
hint is provided.
The same namespace can be used both as the namespace
of elements and attributes appearing in the schema document,
and in the course of
defining schema components in terms of foreign
components.
The import in this example is necessary because there is a reference to the element
component
xhtml:p.
if there were no component reference, then
the import would be unnecessary; no import is needed for use of a namespace
in a
or similar schema document element or attribute name.
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xhtml="http://www.w3.org/1999/xhtml"
targetNamespace="uri:mywork" xmlns:my="uri:mywork">
<xs:import namespace="http://www.w3.org/1999/xhtml"/>
<xs:annotation>
<xs:documentation>
<!--* The XHTML 'p' element below requires us to
define a prefix for the XHTML namespace, but it
does NOT require us to import the XHTML
namespace into the schema. The use of XHTML
(or other) markup here is allowed by the lax
wildcard in the schema for schema documents.
*-->
<xhtml:p>[Some documentation for my schema]</xhtml:p>
</xs:documentation>
</xs:annotation>
. . .
<xs:complexType name="myType">
<xs:sequence>
<xs:element ref="xhtml:p" minOccurs="0"/>
</xs:sequence>
. . .
</xs:complexType>
<xs:element name="myElt" type="my:myType"/>
</xs:schema>
Since
component references are given as QNames,
and since the default namespace declaration can
only be used for one of the target namespace and the XSD namespace
(which typically differ, except
in the case of the schema for schema documents),
either internal references to the names being defined in a schema document
or the schema declaration and definition elements themselves
will normally be explicitly qualified.
This example takes the first option — most other
examples in this specification have taken the second.
Providing Hints for Imported Schema Document Locations
The actual value of the schemaLocationattribute, if present on
an element, gives a hint as to where a
serialization of a schema document with declarations and definitions for the
imported namespace (or none) can
possibly be found. When no schemaLocationattribute is present, the schema author is leaving the
identification of that schema to the instance, application or user,
via the mechanisms described below in . When a
schemaLocationattribute
is present, it must contain a single URI reference which
the schema author warrants will resolve to a
serialization of a schema document containing
definitions and declarations of
component(s) in the
ed namespace.
Conformance profiles may further
restrict the use of the schemaLocation attribute. For example,
one profile might mandate that the hint be
honored by the schema software, perhaps calling for a
processor-dependent error should the URI fail to resolve,
or mandating that the hint agree with some expected URI value;
another profile might mandate that the hint not
be honored,
etc.
Since both the namespace and schemaLocationattribute are optional, a bare <import/> information item
is allowed. This simply allows unqualified reference to foreign
components with no target namespace without giving any hints as to where to find them.
Import Constraints and Semantics
In addition to the conditions imposed on element
information items by the schema for schema documents
the namespaceattribute is present
its actual valuedoes not match the actual value of the
enclosing 's targetNamespaceattribute.
the namespaceattribute is not present
the enclosing has a targetNamespaceattribute
If the application schema reference strategy succeeds using the actual values of
the schemaLocation and namespaceattributes
The result is (a fragment of) a resource which is an XML document
(see ), which in turn corresponds to a
element information item in a well-formed information set, which in turn
corresponds to a conforming schema.
The result is a
element information item in a well-formed information set, which in turn
corresponds to a conforming schema.
In either case call the item D2 and the conforming schemaS2.
If D2 exists, that is, or
above were satisfied, then
there is a namespaceattribute
its actual valueis identical to the actual value of the targetNamespaceattribute of D2.
there is no namespaceattribute
D2has no targetNamespaceattribute
It is not an error for the application schema component reference strategy to fail.
It is an error for it to succeed but
the rest of above to
fail to be satisfied. Failure is likely to cause
less than complete
outcomes, of course.
The schema components (that is
, , , , ,
) of a schema
corresponding to a
element information item with one or more
element information items must include not
only definitions or declarations corresponding to the appropriate
members of its children, but also, for each of those element information items for which above is satisfied, a set of schema
components identical to all the schema
components of S2
(with the possible
exception of the component
of S2).
The above is carefully worded so that
multiple ing of the same schema document will not constitute a
violation of
of , but
applications are allowed, indeed encouraged, to avoid ing the
same schema document more than once to forestall the necessity of
establishing identity component by component. Given that the
schemaLocationattribute is only a hint, it is open
to applications to ignore all but the first for
a given namespace, regardless of the
actual value of schemaLocation, but such a strategy risks
missing useful information when new schemaLocations are
offered.
Layer 3: Schema Document Access and Web-interoperability
Layers 1 and 2 provide a framework for and XML definition of schemas in a
broad variety of environments. Over time, it is possible that a range of standards and
conventions will evolve to support
interoperability of XSD implementations on the World Wide Web.
Layer 3 defines the minimum level of function required of all
conformant processors operating on the Web: it is intended that, over
time, future standards (e.g. XML Packages) for interoperability on the
Web and in other environments can be introduced without the need to
republish this specification.
Standards for representation of schemas and retrieval of schema documents on the Web
For interoperability, serialized schema documents, like all other Web
resources, should be identified by URI and
retrieved using the standard mechanisms of the Web (e.g. http, https,
etc.) Such documents on the Web must be part of XML documents (see
), and are represented in the standard XML
schema definition form described by layer 2 (that is as
element information items).
there will often be times when a schema document will be a
complete XML document whose document element is . There will be
other occasions in which items will be contained in other
documents, perhaps referenced using fragment and/or
notation.
The variations among server software and web site administration policies
make it difficult to recommend any particular approach to retrieval requests
intended to retrieve serialized schema documents. An Accept header of application/xml,
text/xml; q=0.9, */* is perhaps a reasonable starting point.
How schema definitions are located on the Web
As described in , processors are responsible for providing the
schema components (definitions and declarations) needed for . This
section introduces a set of conventions to facilitate interoperability
for instance and schema documents retrieved and processed from the Web.
As discussed above in , other non-Web
mechanisms for delivering schemas for exist, but are outside the scope of this
specification.
Processors on the Web are free to undertake against arbitrary
schemas in any of the ways set out in . However, it
is useful to have a common convention for determining the schema to use. Accordingly, general-purpose schema-aware processors (i.e. those not
specialized to one or a fixed set of pre-determined schemas)
undertaking of an instance document on the web
must behave as follows:
unless directed otherwise by the user, is undertaken on the document
element information item of the
instance document;
unless directed otherwise by the user, the
processor is required to construct a schema corresponding to a schema document
whose targetNamespace is
identical to the
namespace name, if any, of the element information item on which is undertaken.
The composition of the complete
schema for use in is discussed in above.
The means used to locate appropriate schema document(s) are processor and
application dependent, subject to the following requirements:
Schemas are represented on the Web in the form specified above in ;
The author of a document uses namespace declarations to
indicate the intended interpretation of names appearing therein;
it is possible but not guaranteed that
a schema is retrievable via
the namespace name. Accordingly whether a processor's default
behavior is or is not to attempt such dereferencing, it must always
provide for user-directed overriding of that default.
Experience suggests that it is not in all cases safe or desirable from
a performance point of view to dereference namespace names as a matter of course. User community and/or
consumer/provider agreements may
establish circumstances in which such dereference is a sensible
default strategy: this specification allows but does not require particular communities to
establish and implement such conventions. Users are always free to supply namespace names as schema location information when dereferencing is desired: see below.
On the other hand, in case a document author (human or not) created a
document with a particular schema in view, and warrants that some or
all of the document conforms to that schema, the
xsi:schemaLocation
and xsi:noNamespaceSchemaLocationattributes are provided. The first records
the author's warrant with pairs of URI references (one for the namespace name, and
one for a hint as to the location of a schema document defining names for that
namespace name). The second similarly provides a URI reference as a hint as to
the location of a schema document with no targetNamespaceattribute.
Processors may
attempt to dereference each schema document location URI in the
actual value of such
xsi:schemaLocation and xsi:noNamespaceSchemaLocationattributes.
Schema processors should provide an option to
control whether they do so.It is not an error for such
an attempt to fail, but failure may cause less than complete
outcomes.
Whether schema location information in the document
instance should or should not be dereferenced may vary with
the purpose in view.
When systems rely on an input document being schema-valid
with respect to a particular agreed-upon schema, it is
important that they be able to have complete control over the
choice of schema used in assessment and in particular that
they be able to instruct the processor not to
follow any schemaLocation hints in the input.
Otherwise, the input document could circumvent the agreement
and the consumer's validation of the input, by referring to
an alternative schema for the same namespaces, which declares
the input document schema-valid but which does not adhere to
the prior agreement between the data source and the data
consumer.
In other cases the purpose of assessment may be not to
enforce a prior agreement between data source and consumer,
but to annotate the input with type definitions and other
useful information from the post-schema-validation infoset. In such cases it will
often be better to follow the schemaLocation hints.
Users who need to exert control over the choice of schema can
normally be expected to be aware of the requirement;
conversely, users unaware of the issue will typically be
those who are not relying on the use of a particular schema
to enforce a specific agreement with the data source. Casual
users will often benefit from a default behavior of following
schemaLocation hints.
Useful guidance on how to present this and other questions to
end users may be found in the W3C's User Agent Accessibility
Guidelines , .
When schema location values (i.e. schemaLocation attributes on
, , ,
and in schema documents, or
xsi:schemaLocation and xsi:noNamespaceSchemaLocation
attributes in instance documents) are dereferenced and the values are relative
references, then the base URI of the
owner elementmust be used to resolve the relative references.
According to the rules of
, the corresponding schema may be lazily assembled, but is otherwise
stable throughout . Although schema location attributes can occur
on any element, and can be processed incrementally as discovered, their effect
is essentially global to the . Definitions and declarations remain
in effect beyond the scope of the element on which the binding is declared.
Multiple schema bindings can be declared using a single
attribute. For example consider a stylesheet:
The namespace names used in schemaLocation can, but need not
be identical to those actually qualifying the element within whose start tag
it is found or its other attributes. For example, as above, all
schema location information can be declared on the document element
of a document, if desired,
regardless of where the namespaces are actually used.
Improved or alternative conventions for Web interoperability can
be standardized in the future without reopening this specification. For
example, the W3C is currently considering initiatives to standardize the
packaging of resources relating to particular documents and/or namespaces: this
would be an addition to the mechanisms described here for layer 3. This
architecture also facilitates innovation at layer 2: for example, it would be
possible in the future to define an additional standard for the representation of
schema components which allowed e.g. type definitions to be specified piece by
piece, rather than all at once.
Schemas and Schema-validity Assessment
The architecture of schema-aware processing allows for a rich
characterization of XML documents: schema validity is not a binary
predicate.
This specification distinguishes between errors in schema
construction and structure, on the one hand, and schema validation
outcomes, on the other.
Errors in Schema Construction and Structure
Before can be
attempted, a schema is required. Special-purpose applications are
free to determine a schema for use in by whatever means are
appropriate, but general purpose processors should implement
and document a strategy for assembling a schema,
exploiting at least some if not all of the non-hard-coded
methods outlined in ,
starting with the namespaces declared in the document whose
is being undertaken,
and the actual values of the xsi:schemaLocation and
xsi:noNamespaceSchemaLocationattributes
thereof, if any, along with any other information about schema
identity or schema document location provided by users in
application-specific ways, if any.
It is an error if a schema and all the components which are the
value of any of its properties, recursively, fail to satisfy all
the relevant Constraints on Schemas set out in the last section
of each of the subsections of .
If a schema is derived from one or more schema documents (that
is, one or more element information items)
based on the
correspondence rules set out in and
, two additional conditions
hold; both apply to the
schema document after the conditional-inclusion
pre-processing described in is
performed:
It is an error if any such schema document would not be
fully valid with respect to a schema corresponding to the
, that is, following
schema-validation with such a schema, the element information items would have a
property with value
full or partial and a
property with value
valid.
It is an error if any such schema document is or contains
any element information items which violate any of the
relevant Schema Representation Constraints set out in .
The cases described above are the only types of error
which this specification defines. With respect to the processes
of the checking of schema structure and the construction of
schemas corresponding to schema documents, this specification
imposes no restrictions on processors in the
presence of errors, beyond the
requirement that if there are errors in a schema, or in one
or more
schema documents used in constructing a schema, then a
conforming processor must report
the fact.
However, any further
operations performed in the
presence of errors are outside the scope of this specification
and are not schema-validity
assessment as that term is defined here.
Assessing Schema-Validity
With a schema which satisfies the conditions expressed in above, the schema-validity of an
element or attribute
information item (the
) can be assessed. Five
primary approaches to this are described
and given names here; conforming processors may but are not required
to provide interfaces so that they can be invoked in ways consistent
with any or all of these approaches.
The user or application identifies a type definition from among the type
definitions of the schema. If the
is an element, then it is validated as described
in
(with the stipulated type definition
as the ); if it is an
attribute, then it is validated with respect to that type definition
as described in .
Top-level (named) types should be supported;
support for local types is optional.
The user or application identifies an element declaration from among the element
declarations of the schema and the
item is validated as described in (with
the stipulated element declaration as the declaration);
Top-level elements
should be supported; support for local elements is optional.
The user or application identifies an attribute declaration from
among the attribute declarations of the schema and the item is validated as described in
(with
the stipulated attribute declaration as its
declaration);
The processor starts from with
no stipulated declaration or definition. If the and the schema determine an
element declaration (by the name of the element), an attribute
declaration (by the name of the attribute), or a type definition (by
xsi:type), then strict
validation is performed. If they do
not identify any declaration or definition, then
lax assessment is
performed.
The name for this method of
invocation reflects the fact that it is analogous to the validation of
an element information item which matches a lax
wildcard.
The processor starts from with no
stipulated declaration or definition. If the
and the schema determine an element declaration (by the name of the element),
an attribute declaration (by the name of the attribute), or a
type definition (via xsi:type), then strictvalidation is
performed; if they do not identify any declaration or
definition, then
lax assessment is performed.
From the point of view of schema-validity assessment and the
resulting post-schema-validation infoset, lax and strict wildcard validation
produce
the same result.
The distinction is provided in order to provide two different terms
to express the different expectations of the invoking process.
In typical cases strict wildcard validation will be
performed when the invoking process expects the
to be declared and valid and will otherwise
report an error to its environment. If the absence of
a declaration for the counts as a successful
outcome of validation, then it is preferable to use
lax wildcard
validation instead.
The name for this method of invocation
reflects the fact that it is analogous to the
validation of an element information item which matches a
strict wildcard.
For type-, element-, and attribute-driven validation,
there is no requirement that the declaration or definition
identified by the user or application be a top-level
component of the schema. Mechanisms for referring to
other components are out of scope for this specification,
but see .
The element or attribute information item at which begins is called the
validation root.
The outcome of schema-validity
assessment will be manifest in the validation attempted and validity properties on the , and if the
is an element information item then also
on its attributes and children, recursively, as
defined by and . There is no
requirement that input which is not schema-valid be rejected by an
application. It is up to applications to decide what
constitutes a successful outcome of
validation.
Note that every element and attribute information item
participating in the will
also have a validation context
property which refers back to the .
This specification does not reconstruct the XML notion of
root in either schemas or instances. Equivalent
functionality is provided for at
invocation, via above.
This specification has nothing normative to say about multiple
episodes. It should
however be clear from the above that if a processor restarts with respect to a post-schema-validation infoset some post-schema-validation infoset
contributions from the previous are likely
to be overwritten. Restarting can
nonetheless be useful, particularly at a node whose validation attempted property is
none, in which case there are three obvious cases in which
additional useful information could
result:
was not attempted
because of a validation failure, but
declarations and/or definitions are available for at least some of the
children or attributes;
was not attempted
because a named definition or declaration was missing, but after
further effort the processor has retrieved it.
was not attempted
because it was
,
but the processor has at least some
declarations and/or definitions available for at least some of the
children or attributes.
Missing Sub-components
At the beginning of , attention is drawn to the
fact that most kinds of schema components have properties which are described therein
as having other components, or sets of other components, as values, but that
when components are constructed on the basis of their correspondence with
element information items in schema documents, such properties usually
correspond to QNames, and the
resolution of such QNamescan fail, resulting in one or more values of or containing absent where a component is mandated.
If at any time during , an element or attribute
information item is being validated with respect to a component of
any kind any of whose properties has or contains such an absent value,
the validation is modified,
as following:
In the case of
attribute information items, the effect is as if
of had
failed;
In the case of
element information items, the effect is as if
of had
failed;
In the case of element information items, processors
must fall back tolax assessment.
Because of the value specification for in , if this situation ever arises, the
document as a whole cannot show a
of full.
References in a to
unknown
datatypes, or to
unknown
constraining facets, make the
simple type definition unusable in ways similar to
having absent property values. Often, such references will
result in component properties with absent values, but
not necessarily. In either case they,
and likewise any types derived or constructed from them,
are handled in the same way as described above for components
with absent property values.
Responsibilities of Schema-aware Processors
Schema-aware processors are responsible for processing XML documents,
schemas and schema documents, as appropriate given the level of conformance
(as defined in ) they support,
consistently with the conditions set out above.
Schema for Schema Documents (Structures) (normative)
The XML representation of the schema for schema documents is
presented here as a normative part of the specification, and as an
illustrative example of how the XML Schema Definition Language can define itself
using its own constructs. The names of XSD types,
elements, attributes and groups defined here are evocative of their
purpose, but are occasionally verbose.
There is some annotation in comments, but a fuller annotation will
require the use of embedded documentation facilities or a hyperlinked
external annotation for which tools are not yet readily available.
Like any other XML document, schema
documents may carry XML and document type declarations. An XML
declaration and a document type declaration are provided here for
convenience. Since this schema document describes the XSD
language, the targetNamespace attribute on the
schema element refers to the XSD namespace
itself.
Schema documents conforming to this specification may be in XML
1.0 or XML 1.1. Conforming implementations may accept input in
XML 1.0 or XML 1.1 or both. See .
Independent copies of this material are
available in an undated (mutable) version at
and in a dated (immutable) version at
— the mutable version will be updated with future revisions of
this specification, and the immutable one will not.
Schema for schema documents
<?xml version='1.0'?>
<!DOCTYPE xs:schema PUBLIC "-//W3C//DTD XMLSCHEMA 200102//EN" "XMLSchema.dtd" [
<!-- provide ID type information even for parsers which only read the
internal subset -->
<!ATTLIST xs:schema id ID #IMPLIED>
<!ATTLIST xs:complexType id ID #IMPLIED>
<!ATTLIST xs:complexContent id ID #IMPLIED>
<!ATTLIST xs:simpleContent id ID #IMPLIED>
<!ATTLIST xs:extension id ID #IMPLIED>
<!ATTLIST xs:element id ID #IMPLIED>
<!ATTLIST xs:group id ID #IMPLIED>
<!ATTLIST xs:all id ID #IMPLIED>
<!ATTLIST xs:choice id ID #IMPLIED>
<!ATTLIST xs:sequence id ID #IMPLIED>
<!ATTLIST xs:any id ID #IMPLIED>
<!ATTLIST xs:anyAttribute id ID #IMPLIED>
<!ATTLIST xs:attribute id ID #IMPLIED>
<!ATTLIST xs:attributeGroup id ID #IMPLIED>
<!ATTLIST xs:unique id ID #IMPLIED>
<!ATTLIST xs:key id ID #IMPLIED>
<!ATTLIST xs:keyref id ID #IMPLIED>
<!ATTLIST xs:selector id ID #IMPLIED>
<!ATTLIST xs:field id ID #IMPLIED>
<!ATTLIST xs:assert id ID #IMPLIED>
<!ATTLIST xs:include id ID #IMPLIED>
<!ATTLIST xs:import id ID #IMPLIED>
<!ATTLIST xs:redefine id ID #IMPLIED>
<!ATTLIST xs:override id ID #IMPLIED>
<!ATTLIST xs:notation id ID #IMPLIED>
]>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" xml:lang="EN"
targetNamespace="http://www.w3.org/2001/XMLSchema"
version="structures.xsd (wd-20091203)">
<xs:annotation>
<xs:documentation source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html">
The schema corresponding to this document is normative,
with respect to the syntactic constraints it expresses in the
XML Schema Definition Language. The documentation (within <documentation> elements)
below, is not normative, but rather highlights important aspects of
the W3C Recommendation of which this is a part.
See below (at the bottom of this document) for information about
the revision and namespace-versioning policy governing this
schema document.
</xs:documentation>
</xs:annotation>
<xs:annotation>
<xs:documentation>
The simpleType element and all of its members are defined
in datatypes.xsd</xs:documentation>
</xs:annotation>
<xs:include schemaLocation="datatypes.xsd"/>
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd">
<xs:annotation>
<xs:documentation>
Get access to the xml: attribute groups for xml:lang
as declared on 'schema' and 'documentation' below
</xs:documentation>
</xs:annotation>
</xs:import>
<xs:complexType name="openAttrs">
<xs:annotation>
<xs:documentation>
This type is extended by almost all schema types
to allow attributes from other namespaces to be
added to user schemas.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="annotated">
<xs:annotation>
<xs:documentation>
This type is extended by all types which allow annotation
other than <schema> itself
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="xs:openAttrs">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:group name="schemaTop">
<xs:annotation>
<xs:documentation>
This group is for the
elements which occur freely at the top level of schemas.
All of their types are based on the "annotated" type by extension.</xs:documentation>
</xs:annotation>
<xs:choice>
<xs:group ref="xs:redefinable"/>
<xs:element ref="xs:element"/>
<xs:element ref="xs:attribute"/>
<xs:element ref="xs:notation"/>
</xs:choice>
</xs:group>
<xs:group name="redefinable">
<xs:annotation>
<xs:documentation>
This group is for the
elements which can self-redefine (see <redefine> below).</xs:documentation>
</xs:annotation>
<xs:choice>
<xs:element ref="xs:simpleType"/>
<xs:element ref="xs:complexType"/>
<xs:element ref="xs:group"/>
<xs:element ref="xs:attributeGroup"/>
</xs:choice>
</xs:group>
<xs:simpleType name="formChoice">
<xs:annotation>
<xs:documentation>
A utility type, not for public use</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="qualified"/>
<xs:enumeration value="unqualified"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="reducedDerivationControl">
<xs:annotation>
<xs:documentation>
A utility type, not for public use</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:derivationControl">
<xs:enumeration value="extension"/>
<xs:enumeration value="restriction"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="derivationSet">
<xs:annotation>
<xs:documentation>
A utility type, not for public use</xs:documentation>
<xs:documentation>
#all or (possibly empty) subset of {extension, restriction}</xs:documentation>
</xs:annotation>
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="#all"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:list itemType="xs:reducedDerivationControl"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="typeDerivationControl">
<xs:annotation>
<xs:documentation>
A utility type, not for public use</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:derivationControl">
<xs:enumeration value="extension"/>
<xs:enumeration value="restriction"/>
<xs:enumeration value="list"/>
<xs:enumeration value="union"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="fullDerivationSet">
<xs:annotation>
<xs:documentation>
A utility type, not for public use</xs:documentation>
<xs:documentation>
#all or (possibly empty) subset of {extension, restriction, list, union}</xs:documentation>
</xs:annotation>
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="#all"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:list itemType="xs:typeDerivationControl"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:element name="schema" id="schema">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-schema"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:openAttrs">
<xs:sequence>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="xs:include"/>
<xs:element ref="xs:import"/>
<xs:element ref="xs:redefine"/>
<xs:element ref="xs:override"/>
<xs:element ref="xs:annotation"/>
</xs:choice>
<xs:sequence minOccurs="0">
<xs:element ref="xs:defaultOpenContent"/>
<xs:element ref="xs:annotation" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:group ref="xs:schemaTop"/>
<xs:element ref="xs:annotation" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:sequence>
<xs:attribute name="targetNamespace" type="xs:anyURI"/>
<xs:attribute name="version" type="xs:token"/>
<xs:attribute name="finalDefault" type="xs:fullDerivationSet"
default="" use="optional"/>
<xs:attribute name="blockDefault" type="xs:blockSet" default=""
use="optional"/>
<xs:attribute name="attributeFormDefault" type="xs:formChoice"
default="unqualified" use="optional"/>
<xs:attribute name="elementFormDefault" type="xs:formChoice"
default="unqualified" use="optional"/>
<xs:attribute name="defaultAttributes" type="xs:QName"/><xs:attribute name="xpathDefaultNamespace" type="xs:xpathDefaultNamespace"
default="##local" use="optional"/>
<xs:attribute name="id" type="xs:ID"/>
<xs:attribute ref="xml:lang"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:key name="element">
<xs:selector xpath="xs:element"/>
<xs:field xpath="@name"/>
</xs:key>
<xs:key name="attribute">
<xs:selector xpath="xs:attribute"/>
<xs:field xpath="@name"/>
</xs:key>
<xs:key name="type">
<xs:selector xpath="xs:complexType|xs:simpleType"/>
<xs:field xpath="@name"/>
</xs:key>
<xs:key name="group">
<xs:selector xpath="xs:group"/>
<xs:field xpath="@name"/>
</xs:key>
<xs:key name="attributeGroup">
<xs:selector xpath="xs:attributeGroup"/>
<xs:field xpath="@name"/>
</xs:key>
<xs:key name="notation">
<xs:selector xpath="xs:notation"/>
<xs:field xpath="@name"/>
</xs:key>
<xs:key name="identityConstraint">
<xs:selector xpath=".//xs:key|.//xs:unique|.//xs:keyref"/>
<xs:field xpath="@name"/>
</xs:key>
</xs:element>
<xs:simpleType name="allNNI">
<xs:annotation>
<xs:documentation>
for maxOccurs</xs:documentation>
</xs:annotation>
<xs:union memberTypes="xs:nonNegativeInteger">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="unbounded"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:attributeGroup name="occurs">
<xs:annotation>
<xs:documentation>
for all particles</xs:documentation>
</xs:annotation>
<xs:attribute name="minOccurs" type="xs:nonNegativeInteger" default="1"
use="optional"/>
<xs:attribute name="maxOccurs" type="xs:allNNI" default="1" use="optional"/>
</xs:attributeGroup>
<xs:attributeGroup name="defRef">
<xs:annotation>
<xs:documentation>
for element, group and attributeGroup,
which both define and reference</xs:documentation>
</xs:annotation>
<xs:attribute name="name" type="xs:NCName"/>
<xs:attribute name="ref" type="xs:QName"/>
</xs:attributeGroup>
<xs:group name="typeDefParticle">
<xs:annotation>
<xs:documentation>
'complexType' uses this</xs:documentation>
</xs:annotation>
<xs:choice>
<xs:element name="group" type="xs:groupRef"/>
<xs:element ref="xs:all"/>
<xs:element ref="xs:choice"/>
<xs:element ref="xs:sequence"/>
</xs:choice>
</xs:group>
<xs:group name="nestedParticle">
<xs:choice>
<xs:element name="element" type="xs:localElement"/>
<xs:element name="group" type="xs:groupRef"/>
<xs:element ref="xs:choice"/>
<xs:element ref="xs:sequence"/>
<xs:element ref="xs:any"/>
</xs:choice>
</xs:group>
<xs:group name="particle">
<xs:choice>
<xs:element name="element" type="xs:localElement"/>
<xs:element name="group" type="xs:groupRef"/>
<xs:element ref="xs:all"/>
<xs:element ref="xs:choice"/>
<xs:element ref="xs:sequence"/>
<xs:element ref="xs:any"/>
</xs:choice>
</xs:group>
<xs:complexType name="attribute">
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:sequence>
<xs:element name="simpleType" type="xs:localSimpleType" minOccurs="0"/>
</xs:sequence>
<xs:attributeGroup ref="xs:defRef"/>
<xs:attribute name="type" type="xs:QName"/>
<xs:attribute name="use" default="optional" use="optional">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="prohibited"/>
<xs:enumeration value="optional"/>
<xs:enumeration value="required"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="default" type="xs:string"/>
<xs:attribute name="fixed" type="xs:string"/>
<xs:attribute name="form" type="xs:formChoice"/>
<xs:attribute name="targetNamespace" type="xs:anyURI"/>
<xs:attribute name="inheritable" type="xs:boolean"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="topLevelAttribute">
<xs:complexContent>
<xs:restriction base="xs:attribute">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:element name="simpleType" type="xs:localSimpleType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="ref" use="prohibited"/>
<xs:attribute name="form" use="prohibited"/>
<xs:attribute name="use" use="prohibited"/>
<xs:attribute name="targetNamespace" use="prohibited"/>
<xs:attribute name="name" type="xs:NCName" use="required"/>
<xs:attribute name="inheritable" type="xs:boolean"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:group name="attrDecls">
<xs:sequence>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="attribute" type="xs:attribute"/>
<xs:element name="attributeGroup" type="xs:attributeGroupRef"/>
</xs:choice>
<xs:element ref="xs:anyAttribute" minOccurs="0"/>
</xs:sequence>
</xs:group>
<xs:element name="anyAttribute" id="anyAttribute">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-anyAttribute"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:wildcard">
<xs:attribute name="notQName" type="xs:qnameListA"
use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:group name="assertions">
<xs:sequence>
<xs:element name="assert" type="xs:assertion"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:group>
<xs:complexType name="assertion">
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:attribute name="test" type="xs:string"/><xs:attribute name="xpathDefaultNamespace" type="xs:xpathDefaultNamespace"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:group name="complexTypeModel">
<xs:choice>
<xs:element ref="xs:simpleContent"/>
<xs:element ref="xs:complexContent"/>
<xs:sequence>
<xs:annotation>
<xs:documentation>
This branch is short for
<complexContent>
<restriction base="xs:anyType">
...
</restriction>
</complexContent></xs:documentation>
</xs:annotation>
<xs:element ref="xs:openContent" minOccurs="0"/>
<xs:group ref="xs:typeDefParticle" minOccurs="0"/>
<xs:group ref="xs:attrDecls"/>
<xs:group ref="xs:assertions"/>
</xs:sequence>
</xs:choice>
</xs:group>
<xs:complexType name="complexType" abstract="true">
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:group ref="xs:complexTypeModel"/>
<xs:attribute name="name" type="xs:NCName">
<xs:annotation>
<xs:documentation>
Will be restricted to required or prohibited</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="mixed" type="xs:boolean" use="optional">
<xs:annotation>
<xs:documentation>
Not allowed if simpleContent child is chosen.
May be overridden by setting on complexContent child.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="abstract" type="xs:boolean" default="false"
use="optional"/>
<xs:attribute name="final" type="xs:derivationSet"/>
<xs:attribute name="block" type="xs:derivationSet"/>
<xs:attribute name="defaultAttributesApply" type="xs:boolean"
default="true" use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="topLevelComplexType">
<xs:complexContent>
<xs:restriction base="xs:complexType">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:group ref="xs:complexTypeModel"/>
</xs:sequence>
<xs:attribute name="name" type="xs:NCName" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="localComplexType">
<xs:complexContent>
<xs:restriction base="xs:complexType">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:group ref="xs:complexTypeModel"/>
</xs:sequence>
<xs:attribute name="name" use="prohibited"/>
<xs:attribute name="abstract" use="prohibited"/>
<xs:attribute name="final" use="prohibited"/>
<xs:attribute name="block" use="prohibited"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="restrictionType">
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:sequence>
<xs:choice minOccurs="0">
<xs:sequence>
<xs:element ref="xs:openContent" minOccurs="0"/>
<xs:group ref="xs:typeDefParticle"/>
</xs:sequence>
<xs:group ref="xs:simpleRestrictionModel"/>
</xs:choice>
<xs:group ref="xs:attrDecls"/>
<xs:group ref="xs:assertions"/>
</xs:sequence>
<xs:attribute name="base" type="xs:QName" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="complexRestrictionType">
<xs:complexContent>
<xs:restriction base="xs:restrictionType">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:choice minOccurs="0">
<xs:annotation>
<xs:documentation>This choice is added simply to
make this a valid restriction per the REC</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element ref="xs:openContent" minOccurs="0"/>
<xs:group ref="xs:typeDefParticle"/>
</xs:sequence>
</xs:choice>
<xs:group ref="xs:attrDecls"/>
<xs:group ref="xs:assertions"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="extensionType">
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:sequence>
<xs:element ref="xs:openContent" minOccurs="0"/>
<xs:group ref="xs:typeDefParticle" minOccurs="0"/>
<xs:group ref="xs:attrDecls"/>
<xs:group ref="xs:assertions"/>
</xs:sequence>
<xs:attribute name="base" type="xs:QName" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="complexContent" id="complexContent">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-complexContent"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:choice>
<xs:element name="restriction" type="xs:complexRestrictionType"/>
<xs:element name="extension" type="xs:extensionType"/>
</xs:choice>
<xs:attribute name="mixed" type="xs:boolean">
<xs:annotation>
<xs:documentation>
Overrides any setting on complexType parent.</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="openContent" id="openContent">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-openContent"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:sequence>
<xs:element name="any" minOccurs="0" type="xs:wildcard"/>
</xs:sequence>
<xs:attribute name="mode" default="interleave" use="optional">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="none"/>
<xs:enumeration value="interleave"/>
<xs:enumeration value="suffix"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="defaultOpenContent" id="defaultOpenContent">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-defaultOpenContent"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:sequence>
<xs:element name="any" type="xs:wildcard"/>
</xs:sequence>
<xs:attribute name="appliesToEmpty" type="xs:boolean"
default="false" use="optional"/>
<xs:attribute name="mode" default="interleave" use="optional">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="interleave"/>
<xs:enumeration value="suffix"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:complexType name="simpleRestrictionType">
<xs:complexContent>
<xs:restriction base="xs:restrictionType">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:choice minOccurs="0">
<xs:annotation>
<xs:documentation>This choice is added simply to
make this a valid restriction per the REC</xs:documentation>
</xs:annotation>
<xs:group ref="xs:simpleRestrictionModel"/>
</xs:choice>
<xs:group ref="xs:attrDecls"/>
<xs:group ref="xs:assertions"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="simpleExtensionType">
<xs:complexContent>
<xs:restriction base="xs:extensionType">
<xs:sequence>
<xs:annotation>
<xs:documentation>
No typeDefParticle group reference</xs:documentation>
</xs:annotation>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:group ref="xs:attrDecls"/>
<xs:group ref="xs:assertions"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="simpleContent" id="simpleContent">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-simpleContent"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:choice>
<xs:element name="restriction" type="xs:simpleRestrictionType"/>
<xs:element name="extension" type="xs:simpleExtensionType"/>
</xs:choice>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="complexType" type="xs:topLevelComplexType" id="complexType">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-complexType"/>
</xs:annotation>
</xs:element>
<xs:simpleType name="blockSet">
<xs:annotation>
<xs:documentation>
A utility type, not for public use</xs:documentation>
<xs:documentation>
#all or (possibly empty) subset of {substitution, extension,
restriction}</xs:documentation>
</xs:annotation>
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="#all"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:derivationControl">
<xs:enumeration value="extension"/>
<xs:enumeration value="restriction"/>
<xs:enumeration value="substitution"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:complexType name="element" abstract="true">
<xs:annotation>
<xs:documentation>
The element element can be used either
at the top level to define an element-type binding globally,
or within a content model to either reference a globally-defined
element or type or declare an element-type binding locally.
The ref form is not allowed at the top level.</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:sequence>
<xs:choice minOccurs="0">
<xs:element name="simpleType" type="xs:localSimpleType"/>
<xs:element name="complexType" type="xs:localComplexType"/>
</xs:choice>
<xs:element name="alternative" type="xs:altType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:group ref="xs:identityConstraint" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attributeGroup ref="xs:defRef"/>
<xs:attribute name="type" type="xs:QName"/>
<xs:attribute name="substitutionGroup">
<xs:simpleType>
<xs:list itemType="xs:QName"/>
</xs:simpleType>
</xs:attribute>
<xs:attributeGroup ref="xs:occurs"/>
<xs:attribute name="default" type="xs:string"/>
<xs:attribute name="fixed" type="xs:string"/>
<xs:attribute name="nillable" type="xs:boolean" use="optional"/>
<xs:attribute name="abstract" type="xs:boolean" default="false"
use="optional"/>
<xs:attribute name="final" type="xs:derivationSet"/>
<xs:attribute name="block" type="xs:blockSet"/>
<xs:attribute name="form" type="xs:formChoice"/>
<xs:attribute name="targetNamespace" type="xs:anyURI"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="topLevelElement">
<xs:complexContent>
<xs:restriction base="xs:element">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:choice minOccurs="0">
<xs:element name="simpleType" type="xs:localSimpleType"/>
<xs:element name="complexType" type="xs:localComplexType"/>
</xs:choice>
<xs:element name="alternative" type="xs:altType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:group ref="xs:identityConstraint" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ref" use="prohibited"/>
<xs:attribute name="form" use="prohibited"/>
<xs:attribute name="targetNamespace" use="prohibited"/>
<xs:attribute name="minOccurs" use="prohibited"/>
<xs:attribute name="maxOccurs" use="prohibited"/>
<xs:attribute name="name" type="xs:NCName" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="localElement">
<xs:complexContent>
<xs:restriction base="xs:element">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:choice minOccurs="0">
<xs:element name="simpleType" type="xs:localSimpleType"/>
<xs:element name="complexType" type="xs:localComplexType"/>
</xs:choice>
<xs:element name="alternative" type="xs:altType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:group ref="xs:identityConstraint" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="substitutionGroup" use="prohibited"/>
<xs:attribute name="final" use="prohibited"/>
<xs:attribute name="abstract" use="prohibited"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="element" type="xs:topLevelElement" id="element">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-element"/>
</xs:annotation>
</xs:element>
<xs:complexType name="altType">
<xs:annotation>
<xs:documentation>
This type is used for 'alternative' elements.
</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:choice minOccurs="0">
<xs:element name="simpleType" type="xs:localSimpleType"/>
<xs:element name="complexType" type="xs:localComplexType"/>
</xs:choice>
<xs:attribute name="test" type="xs:string" use="optional"/>
<xs:attribute name="type" type="xs:QName" use="optional"/>
<xs:attribute name="xpathDefaultNamespace" type="xs:xpathDefaultNamespace"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="group" abstract="true">
<xs:annotation>
<xs:documentation>
group type for explicit groups, named top-level groups and
group references</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:group ref="xs:particle" minOccurs="0" maxOccurs="unbounded"/>
<xs:attributeGroup ref="xs:defRef"/>
<xs:attributeGroup ref="xs:occurs"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="realGroup">
<xs:complexContent>
<xs:restriction base="xs:group">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:choice minOccurs="0" maxOccurs="1">
<xs:element ref="xs:all"/>
<xs:element ref="xs:choice"/>
<xs:element ref="xs:sequence"/>
</xs:choice>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="namedGroup">
<xs:complexContent>
<xs:restriction base="xs:realGroup">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:choice minOccurs="1" maxOccurs="1">
<xs:element name="all">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:all">
<xs:group ref="xs:allModel"/>
<xs:attribute name="minOccurs" use="prohibited"/>
<xs:attribute name="maxOccurs" use="prohibited"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="choice" type="xs:simpleExplicitGroup"/>
<xs:element name="sequence" type="xs:simpleExplicitGroup"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="name" type="xs:NCName" use="required"/>
<xs:attribute name="ref" use="prohibited"/>
<xs:attribute name="minOccurs" use="prohibited"/>
<xs:attribute name="maxOccurs" use="prohibited"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="groupRef">
<xs:complexContent>
<xs:restriction base="xs:realGroup">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="ref" type="xs:QName" use="required"/>
<xs:attribute name="name" use="prohibited"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="explicitGroup">
<xs:annotation>
<xs:documentation>
group type for the three kinds of group</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:restriction base="xs:group">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:group ref="xs:nestedParticle" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" use="prohibited"/>
<xs:attribute name="ref" use="prohibited"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="simpleExplicitGroup">
<xs:complexContent>
<xs:restriction base="xs:explicitGroup">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:group ref="xs:nestedParticle" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="minOccurs" use="prohibited"/>
<xs:attribute name="maxOccurs" use="prohibited"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:group name="allModel">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>This choice with min/max is here to
avoid a pblm with the Elt:All/Choice/Seq
Particle derivation constraint</xs:documentation>
</xs:annotation>
<xs:element name="element" type="xs:localElement"/>
<xs:element ref="xs:any"/>
<xs:element name="group">
<xs:complexType>
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="ref" type="xs:QName" use="required"/>
<xs:attribute name="minOccurs" fixed="1" type="xs:nonNegativeInteger"/>
<xs:attribute name="maxOccurs" fixed="1" type="xs:nonNegativeInteger"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
</xs:element>
</xs:choice>
</xs:sequence>
</xs:group>
<xs:complexType name="all">
<xs:annotation>
<xs:documentation>
Only elements allowed inside</xs:documentation>
</xs:annotation>
<xs:complexContent>
<xs:restriction base="xs:explicitGroup">
<xs:group ref="xs:allModel"/>
<xs:attribute name="minOccurs" default="1" use="optional">
<xs:simpleType>
<xs:restriction base="xs:nonNegativeInteger">
<xs:enumeration value="0"/>
<xs:enumeration value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="maxOccurs" default="1" use="optional">
<xs:simpleType>
<xs:restriction base="xs:allNNI">
<xs:enumeration value="0"/>
<xs:enumeration value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="all" type="xs:all" id="all">
<xs:annotation>
<xs:documentation source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-all"/>
</xs:annotation>
</xs:element>
<xs:element name="choice" type="xs:explicitGroup" id="choice">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-choice"/>
</xs:annotation>
</xs:element>
<xs:element name="sequence" type="xs:explicitGroup" id="sequence">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-sequence"/>
</xs:annotation>
</xs:element>
<xs:element name="group" type="xs:namedGroup" id="group">
<xs:annotation>
<xs:documentation source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-group"/>
</xs:annotation>
</xs:element>
<xs:attributeGroup name="anyAttrGroup">
<xs:attribute name="namespace" type="xs:namespaceList"
use="optional"/>
<xs:attribute name="notNamespace" use="optional">
<xs:simpleType>
<xs:restriction base="xs:basicNamespaceList">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="processContents" default="strict" use="optional">
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="skip"/>
<xs:enumeration value="lax"/>
<xs:enumeration value="strict"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:attributeGroup>
<xs:complexType name="wildcard">
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:attributeGroup ref="xs:anyAttrGroup"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="any" id="any">
<xs:annotation>
<xs:documentation source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-any"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:wildcard">
<xs:attribute name="notQName" type="xs:qnameList"
use="optional"/>
<xs:attributeGroup ref="xs:occurs"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:annotation>
<xs:documentation>
simple type for the value of the 'namespace' attr of
'any' and 'anyAttribute'</xs:documentation>
</xs:annotation>
<xs:annotation>
<xs:documentation>
Value is
##any - - any non-conflicting WFXML/attribute at all
##other - - any non-conflicting WFXML/attribute from
namespace other than targetNS
##local - - any unqualified non-conflicting WFXML/attribute
one or - - any non-conflicting WFXML/attribute from
more URI the listed namespaces
references
(space separated)
##targetNamespace or ##local may appear in the above list, to
refer to the targetNamespace of the enclosing
schema or an absent targetNamespace respectively</xs:documentation>
</xs:annotation>
<xs:simpleType name="namespaceList">
<xs:annotation>
<xs:documentation>
A utility type, not for public use</xs:documentation>
</xs:annotation>
<xs:union memberTypes="xs:specialNamespaceList xs:basicNamespaceList" />
</xs:simpleType>
<xs:simpleType name="basicNamespaceList">
<xs:annotation>
<xs:documentation>
A utility type, not for public use</xs:documentation>
</xs:annotation>
<xs:list>
<xs:simpleType>
<xs:union memberTypes="xs:anyURI">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="##targetNamespace"/>
<xs:enumeration value="##local"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:list>
</xs:simpleType>
<xs:simpleType name="specialNamespaceList">
<xs:annotation>
<xs:documentation>
A utility type, not for public use</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:token">
<xs:enumeration value="##any"/>
<xs:enumeration value="##other"/>
</xs:restriction>
</xs:simpleType><xs:simpleType name="qnameList">
<xs:annotation>
<xs:documentation>
A utility type, not for public use
</xs:documentation>
</xs:annotation>
<xs:list>
<xs:simpleType>
<xs:union memberTypes="xs:QName">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="##defined"/>
<xs:enumeration value="##definedSibling"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:list>
</xs:simpleType><xs:simpleType name="qnameListA">
<xs:annotation>
<xs:documentation>
A utility type, not for public use
</xs:documentation>
</xs:annotation>
<xs:list>
<xs:simpleType>
<xs:union memberTypes="xs:QName">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="##defined"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
</xs:list>
</xs:simpleType><xs:simpleType name="xpathDefaultNamespace">
<xs:union memberTypes="xs:anyURI">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="##defaultNamespace"/>
<xs:enumeration value="##targetNamespace"/>
<xs:enumeration value="##local"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:element name="attribute" type="xs:topLevelAttribute" id="attribute">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-attribute"/>
</xs:annotation>
</xs:element>
<xs:complexType name="attributeGroup" abstract="true">
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:group ref="xs:attrDecls"/>
<xs:attributeGroup ref="xs:defRef"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="namedAttributeGroup">
<xs:complexContent>
<xs:restriction base="xs:attributeGroup">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:group ref="xs:attrDecls"/>
</xs:sequence>
<xs:attribute name="name" type="xs:NCName" use="required"/>
<xs:attribute name="ref" use="prohibited"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="attributeGroupRef">
<xs:complexContent>
<xs:restriction base="xs:attributeGroup">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="ref" type="xs:QName" use="required"/>
<xs:attribute name="name" use="prohibited"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<xs:element name="attributeGroup" type="xs:namedAttributeGroup"
id="attributeGroup">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-attributeGroup"/>
</xs:annotation>
</xs:element>
<xs:element name="include" id="include">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-include"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="redefine" id="redefine">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-redefine"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:openAttrs">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="xs:annotation"/>
<xs:group ref="xs:redefinable"/>
</xs:choice>
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/>
<xs:attribute name="id" type="xs:ID"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="override" id="override">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-override"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:openAttrs">
<xs:sequence>
<xs:element ref="xs:annotation" minOccurs="0"/>
<xs:group ref="xs:schemaTop" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="schemaLocation" type="xs:anyURI" use="required"/>
<xs:attribute name="id" type="xs:ID"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="import" id="import">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-import"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:attribute name="namespace" type="xs:anyURI"/>
<xs:attribute name="schemaLocation" type="xs:anyURI"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="selector" id="selector">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-selector"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:attribute name="xpath" use="required">
<xs:simpleType>
<xs:annotation>
<xs:documentation>A subset of XPath expressions for use
in selectors</xs:documentation>
<xs:documentation>A utility type, not for public
use</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:token"/>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="xpathDefaultNamespace" type="xs:xpathDefaultNamespace"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="field" id="field">
<xs:annotation>
<xs:documentation source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-field"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:attribute name="xpath" use="required">
<xs:simpleType>
<xs:annotation>
<xs:documentation>A subset of XPath expressions for use
in fields</xs:documentation>
<xs:documentation>A utility type, not for public
use</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:token"/>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="xpathDefaultNamespace" type="xs:xpathDefaultNamespace"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:complexType name="keybase">
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:sequence minOccurs="0">
<xs:element ref="xs:selector"/>
<xs:element ref="xs:field" minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:NCName"/>
<xs:attribute name="ref" type="xs:QName"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:group name="identityConstraint">
<xs:annotation>
<xs:documentation>The three kinds of identity constraints, all with
type of or derived from 'keybase'.
</xs:documentation>
</xs:annotation>
<xs:choice>
<xs:element ref="xs:unique"/>
<xs:element ref="xs:key"/>
<xs:element ref="xs:keyref"/>
</xs:choice>
</xs:group>
<xs:element name="unique" type="xs:keybase" id="unique">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-unique"/>
</xs:annotation>
</xs:element>
<xs:element name="key" type="xs:keybase" id="key">
<xs:annotation>
<xs:documentation source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-key"/>
</xs:annotation>
</xs:element>
<xs:element name="keyref" id="keyref">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-keyref"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:keybase">
<xs:attribute name="refer" type="xs:QName"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="notation" id="notation">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-notation"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:annotated">
<xs:attribute name="name" type="xs:NCName" use="required"/>
<xs:attribute name="public" type="xs:public"/>
<xs:attribute name="system" type="xs:anyURI"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:simpleType name="public">
<xs:annotation>
<xs:documentation>
A utility type, not for public use</xs:documentation>
<xs:documentation>
A public identifier, per ISO 8879</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:token"/>
</xs:simpleType>
<xs:element name="appinfo" id="appinfo">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-appinfo"/>
</xs:annotation>
<xs:complexType mixed="true">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:any processContents="lax"/>
</xs:sequence>
<xs:attribute name="source" type="xs:anyURI"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:element name="documentation" id="documentation">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-documentation"/>
</xs:annotation>
<xs:complexType mixed="true">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:any processContents="lax"/>
</xs:sequence>
<xs:attribute name="source" type="xs:anyURI"/>
<xs:attribute ref="xml:lang"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
</xs:element>
<xs:element name="annotation" id="annotation">
<xs:annotation>
<xs:documentation
source="http://www.w3.org/TR/2009/WD-xmlschema11-1-20091203/structures.html#element-annotation"/>
</xs:annotation>
<xs:complexType>
<xs:complexContent>
<xs:extension base="xs:openAttrs">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element ref="xs:appinfo"/>
<xs:element ref="xs:documentation"/>
</xs:choice>
<xs:attribute name="id" type="xs:ID"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:annotation>
<xs:documentation>
notations for use within schema documents</xs:documentation>
</xs:annotation>
<xs:notation name="XMLSchemaStructures" public="structures"
system="http://www.w3.org/2000/08/XMLSchema.xsd"/>
<xs:notation name="XML" public="REC-xml-19980210"
system="http://www.w3.org/TR/1998/REC-xml-19980210"/>
<xs:complexType name="anyType" mixed="true">
<xs:annotation>
<xs:documentation>
Not the real urType, but as close an approximation as we can
get in the XML representation</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:any minOccurs="0" maxOccurs="unbounded" processContents="lax"/>
</xs:sequence>
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
<xs:annotation>
<xs:documentation>
In keeping with the XML Schema WG's standard versioning policy,
this schema document will persist at the URI
http://www.w3.org/2009/12/XMLSchema.xsd.
At the date of issue it can also be found at the URI
http://www.w3.org/2009/XMLSchema/XMLSchema.xsd.
The schema document at that URI may however change in the future,
in order to remain compatible with the latest version of XSD
and its namespace. In other words, if XSD or the XML Schema
namespace change, the version of this document at
http://www.w3.org/2009/XMLSchema/XMLSchema.xsd will change accordingly;
the version at http://www.w3.org/2009/12/XMLSchema.xsd will not change.
Previous dated (and unchanging) versions of this schema document
include:
http://www.w3.org/2009/04/XMLSchema.xsd
(XSD 1.1 Candidate Recommendation)
http://www.w3.org/2004/10/XMLSchema.xsd
(XSD 1.0 Recommendation, Second Edition)
http://www.w3.org/2001/05/XMLSchema.xsd
(XSD 1.0 Recommendation, First Edition)
</xs:documentation>
</xs:annotation>
</xs:schema>
Outcome Tabulations (normative)
To facilitate consistent reporting of schema errors and validation
failures, this section tabulates and provides unique names for all the
constraints listed in this document. Wherever such constraints have numbered
parts, reports should
use the name given below plus the part number, separated
by a period ('.'). Thus for example cos-ct-extends.1.2should be
used to report a violation of the of
.
Validation Rules
Contributions to the post-schema-validation infoset
Schema Representation Constraints
Schema Component Constraints
Terminology for implementation-defined features (normative)
This section defines some terms for use in describing
choices made by implementations in areas where the
effect of XSD
features is explicitly implementation-defined.
Future versions of this specification are expected to use
the terminology defined here to specify conformance profiles.
Conformance profiles may also be defined by other specifications
without requiring any revision to this specification.
Subset of the Post-schema-validation Infoset
This specification defines a number of ways in which the
information set taken as input is augmented in the course
of schema-validity assessment. Conforming processors may
provide access to some or all of this information; in the
interests of simplifying discussion and documentation, this
section defines names for several subsets of the PSVI, with
the intention of simplifying short-hand descriptions of
processors. These terms may be used to describe what parts of
the PSVI a particular schema processor provides access to, or
to specify requirements for processors, or for other purposes.
A processor provides access to a particular subset
of the PSVI if and only if it makes accessible some representation
of the information in question, for information items to which
it is applicable. (The properties labeled if applicable
or where applicable below are simply the most obvious
cases of properties which do not apply to every information item;
the same qualification implicitly applies to all properties listed
below.)
If other subsets of the PSVI prove important in practice it is
expected that definitions of those subsets may be provided by
other specifications or in later revisions of this one.
The definition in this section of a term denoting a particular
subset of the PSVI does not constitute a requirement that
conforming processors provide access to that subset.
The
root-validity subset of the PSVI consists of the
following properties of the :
, if applicable
The instance-validity subset of the PSVI consists of
the , plus the following properties on elements,
wherever applicable:
and the following properties on attributes, wherever applicable:
The
type-aware subset of the PSVI consists of the
, plus the following
items and properties.
It is intended that the type-aware subset of the PSVI include
all the information needed by schema-aware XQuery 1.0 or
XSLT 2.0 processors.
In each case, the information is to be provided in some
implementation-defined representation. For elements:
(where applicable)
(where applicable)
(where applicable)
and for attributes:
(where applicable)
(where applicable)
(where applicable)
In a future draft of this specification, it is expected that
a list of specific component properties to which access
should or must be provided will be included. No such
list is present in the current draft; input from readers,
users, schema authors, and implementors as to what properties
are most usefully exposed in this subset would be very welcome.
The
lightweight type-aware subset of the PSVI provides
the same information as the
, except that instead of providing
direct access to schema components, it provides only their names and
related information.
For elements:
(where applicable)
(where applicable)
(where applicable)
and for attributes:
(where applicable)
(where applicable)
(where applicable)
The
full instance subset of the PSVI includes almost all
properties defined by this specification as applying to
element and attribute information items, but excludes
schema components. It
consists of
the ,
plus the following properties for elements:
(where applicable)
(where applicable)
(where applicable)
(where applicable)
(where applicable)
(where applicable)
some implementation-defined
representation (including at least the
names of resources from which components were drawn)
and the following for attributes:
(where applicable)
(where applicable)
(where applicable)
(where applicable)
(where applicable)
(where applicable)
The full PSVI with components consists of
every property and information item defined in this
specification.
In exposing element declarations, attribute declarations,
type definitions, and other components, processors
providing access to the full subset must provide some
representation for all of the defined properties of the
components. Note that although the properties are often
redundant with other information, it is not required that
the full subset include more than one representation of
redundant information.
The PSVI is a description of an information set,
not a specification of a data structure or an application-programming
interface. For convenience, this specification defines
in some cases more than one term for denoting a particular
piece of information: for example,
the type definition name
property of an element and the
name
property of the type definition
property of that element are the same piece of information.
If the type definition is
supplied, then the type
definition name is necessarily also available.
Similar observations can be made for other properties present in
the full-instance subset but not mentioned here. Processors
should allow access to the information without requiring
users or applications to distinguish between the different
names or access paths under which it might be described in this
specification.
Terminology of schema construction
Conforming processors may implement any combination of the
following strategies for locating schema components, in any
order. They may also implement other strategies.
The terminology offered here is intended to be useful in
discussions of processor behavior, whether documenting
existing behavior or describing required behavior.
General-purpose processors should support multiple
methods for locating schema documents,
and
provide user
control over which methods are used and how to fall back in
case of failure.
Identifying locations where components are sought
Some terms describe how a processor identifies locations from
which schema components can be sought:
Full knowledge of one or more schemas is built into the
processor. (Note: all processors are required to have some
built-in knowledge of of the built-in components. General-purpose processors
are additionally required to
be able to validate
documents against theXSD schema for schema documents.)
Full knowledge of one or more components is
built into the processor; these components
may be made available automatically by being included
by that processor in every schema it constructs,
or they may be included only under certain
implementation-defined conditions (e.g. an explicit
import of the relevant namespace, or choice of
a specified invocation option).
All processors are
required to have some built-in knowledge of
of the built-in components.
A list of locations at which
schema documents will be sought is built into the processor.
Particular locations can be associated with specific
namespaces or can be used to seek any schema document.
At invocation time, the user passes a set or
sequence of (namespace-name, schema document) pairs to the
processor, e.g. as a command-line option. (Can be used with
early or slow exit strategy.) The namespace name is used
as a check on the document, not as an instruction; if the
schema document has a target namespace which differs from
the namespace name specified, the processor signals an error.
At invocation time, the user passes a set or sequence of schema
documents, or identifiers for schema documents (e.g. URIs), to the
processor, e.g. as a command-line option. Each schema document
is associated with its target namespace, if any.
(Can be used with early or
slow exit strategy.)
For each namespace, the processor asks
the user interactively (though mechanisms not specified
here) where to seek the required schema components.
This will perhaps be most useful as a fallback after other methods
have failed.
For each namespace, the processor attempts
to dereference the namespace name; if a schema document is
returned, it is processed. If some other kind of resource representation is
returned, processors may interpret its content to locate a schema document.
For example, if a RDDL document is returned,
a processor may search the RDDL document for rddl:resource
elements with the well-known property xlink:role
= http://www.w3.org/2001/XMLSchema
and then attempt to dereference the location(s) indicated on the
xlink:href attribute of the link.
For each namespace, if the input
document includes one or more schemaLocation hints for that
namespace, the processor attempts to dereference those
locations.
For each namespace, if a schema document being processed
includes one or more schemaLocation hints for that
namespace (e.g. on an import element,
the processor attempts to dereference those
locations.
For each namespace, a local repository of
schema components is consulted. In some situations the consultation
will require a key, in which see the terminology for indirection
given below.
Identifying methods of indirection
Some terms describe various methods of indirection through
local catalogs, search paths, or local repositories of schema
documents and/or schema components. In each of these, a
‘search key’ is assumed which helps to control the
indirection. Terms for different sorts of search key are
defined below.
The processor has (hard-coded or accepted
as a parameter at invocation time or acquired from the
environment) a series of expressions into which a search key
is substituted. After substitution, each element of the
series is interpreted as a file-system path and a schema
document is sought at the location indicated by that path.
The processor has (hard-coded or accepted
as a parameter at invocation time or acquired from the
environment) a series of expressions into which a search key
is substituted. After substitution, each element of the
series is interpreted as a URI and a schema document is
sought at the location indicated by that path.
The processor consults an OASIS catalog
(whose location can be hard-coded, passed as a parameter at
invocation time or acquired from the environment) using a
search key. The key can be sought for as a namespace name,
as a public identifier, or as a system identifier.
A local repository of schema
components is consulted using a search key.
The location(s) returned by a catalog or other
indirection mechanism are not consulted immediately but
instead used as a key in a renewed indirection. Only after
the indirection mechanism fails to return a value is an
attempt made to dereference the last location returned.
The location(s) returned by a catalog or
other indirection mechanism are consulted immediately; they
are not used in recursive indirections.
Identifying the key for use in indirection
Locating schema components by means of any of the ‘indirect’
methods just identified will sometimes involve the specification of a
value of some kind as a search key. Processors may vary in
their choice of values to use as the key:
The namespace name is used as a key.
A location (e.g. a schema location hint or the
location specified in a catalog or by the user) is used as a
key.
Identifying when to stop searching
When more than one location is available for a given
namespace, two distinct behaviors can be distinguished; these
are orthogonal to other terms defined here:
When more than one location is available for a
given namespace, the processor attempts each in turn. When
a location is successfully dereferenced and a schema
document is obtained, the later locations on the list are
ignored.
When more than one location is available for a
given namespace, the processor attempts each in turn. All
locations are tried, even if a schema document for the
namespace has been obtained.
Identifying how to react to failure
When a processor seeks schema components at a particular
location, but fails to find components of the namespace
in question at that location, several different
ways of responding to that failure can be distinguished:
The processor signals an error in some manner appropriate
to its construction and environment. Some processors
and some users will find it useful to distinguish fatal errors (which
cause processing to halt) from recoverable errors.
The processor signals no fatal error and continues its search
for components in the namespace in question by attempting
another location.
Other Implementation-defined Features
This section defines terms intended to be useful in describing
other implementation-defined choices.
The datatypes defined by , taking
the relevant definitions from
and ,
for datatypes which depend on definitions from those specifications.
The datatypes defined by , taking
the relevant definitions from version 1.1 of
and ,
for datatypes which depend on definitions from those specifications.
Required Information Set Items and Properties (normative)
This specification requires as a precondition for
an information set as defined in which contains
at least the following
information items and properties:
local name, namespace name,
normalized value,
prefix, attribute type,
owner element
character code,
parent
content, parent
local name, namespace name,
children, attributes, in-scope namespaces,namespace attributes,
prefix, base URI,
parent
prefix, namespace name
target, content,
base URI, parent
In addition, infosets should support the unparsed entities
property of the Document Information Item. Failure to do so will mean all
items of type ENTITY or
ENTITIES will fail to
validate. If the
unparsed entities property is supported,
the following is also required:
name,
system identifier,
public identifier
This specification does not require any destructive alterations to the input
information set: all the information set contributions specified herein are additive.
This appendix is intended to satisfy the requirements for Conformance to the specification.
Checklists of implementation-defined and implementation-dependent features (normative)Checklist of implementation-defined features
An implementation-defined
feature or behavior may vary among processors conforming to this
specification; the precise behavior is not specified by
this specification but must be specified by the
implementor for each particular conforming implementation.
(In the latter
respect, features differ
from features.)
This appendix provides a summary of XSD
features whose effect is explicitly implementation-defined.
Any software which claims to conform to this specification
must describe how these choices have been exercised, in
documentation which accompanies any conformance claim.
In describing the choices made for a given processor,
it is hoped that the terminology defined in
will be found useful.
For the datatypes defined by
which depend on
or , it is
implementation-defined whether a schema processor
takes the relevant definitions from
and , or
from
and .
Implementations may support either
the XML-1.0-based
datatypes,
or the XML-1.1-based
datatypes,
or both.
The same applies to the definition of whitespace.
It is implementation-defined whether a schema processor
can read schema documents in the form of XML documents.
Whether a processor
is able to retrieve schema documents from the Web
is implementation-defined. (See ,
which defines processors
as processors
which can retrieve schema documents from the Web.)
The way in which a processor is invoked, and the way in
which values are specified for the schema to be used,
the information item to be validated,
and the declaration or definition with which to begin
validation, is implementation-defined. (See
.)
The manner in which a processor provides access to the
information items and properties in the PSVI to any
downstream or user applications, or to the invoker,
is implementation-defined.
The
information items and properties in the PSVI to which
the processor provides access, if any, is implementation-defined.
(See for some subsets of the PSVI for
which this specification provides names and definitions.)
When the post-schema-validation infoset includes
type definition name and
similar properties, it is implementation-defined whether
unique names are provided for anonymous type definitions.
The method used for assembling a set of schema components
for use in validation is implementation-defined.
(See for the normative prose and
for some terminology which
can be used in describing implementation choices.)
It is implementation-defined whether a schema processor
provides a value for the type definition name
and member type definition name
properties of attribute and element information-items.
If it does so, the choice of name is .
Everything implementation-defined in is also
implementation-defined in this specification.
This includes, but is not limited to, the choice
of XML-1.0-based
or XML-1.1-based
datatypes, or both;
support for implementation-defined primitive datatypes;
and
support for implementation-defined constraining facets.
See the appendix on
implementation-defined and implementation-dependent
features in .
It is implementation-defined whether a processor detects
violations of
of
(a) always by examination of the schema in isolation,
(b) only when some element information item
in the input document is valid against its T but not against T., or
(c) sometimes the one and sometimes the other.
In case (c), the circumstances
in which the processor does one or the other are
implementation-dependent.
Checklist of implementation-dependent features
An implementation-dependent
feature or behavior may vary among processors conforming to this
specification; the precise behavior is not specified by
this or any other W3C specification
and is not required to be specified by the implementor
for any particular implementation. (In the latter
respect, features differ
from features.)
This appendix provides a summary of XSD features whose
effect is explicitly implementation-dependent. Choices made by processors
in these areas are not required to be documented.
When a default value of type QName
or NOTATION is applied to an
element or attribute information item, it is implementation-dependent
whether occurs to ensure that the
maps to the
.
When a default value is supplied for a defaulted attribute and more than
one prefix is bound to the namespace of the attribute in the
in-scope namespaces, it is implementation-dependent which prefix is used for the
attribute.
When a default value is supplied for a defaulted attribute and
is performed, it is implementation-dependent
what prefix is used in the new
namespace information item.
When a default value is supplied for a defaulted attribute and
is performed, it is implementation-dependent
whether the consistency of the information set is preserved by (a) adding
the new binding to the descendants of the element on which the defaulted
attribute occurred, or by (b) undeclaring the new binding on the children
of that element. When rather than
is in use, namespace bindings cannot be
undeclared, so the behavior is implementation-dependent only for those
implementations which do support .
If more than one fails to be satisfied, it is
implementation-dependent which of them are included in the
property of PSVI.
If more than one fails to be satisfied, it is
implementation-dependent which of them are included in the
property of PSVI.
The order of components within various components'
{annotations} property is implementation-dependent.
If a name is supplied for anonymous components
(for example, type definition name
and member type definition name
properties in the post-schema-validation infoset), the choice of name is
implementation-dependent.
If a processor detects
some violations of
of
by examination of the schema in isolation,
and others only when some element information item
in the input document is valid against its T but not against T.,
then the circumstances
in which the processor does one or the other are
implementation-dependent.
Stylesheets for Composing Schema Documents (Normative)
The transformations specified in the following sections
in the form of stylesheets are used when
assembling schemas from multiple schema documents. Implementations do not
have to perform transformation, or use
the stylesheets given here, as long as the
same result is produced.
Transformation for Chameleon Inclusion
When a information item D2 without a
targetNamespaceattribute is included
(), redefined
(), or overridden
() by another D1 with a targetNamespaceattribute, the following
transformation, specified here as an
stylesheet, is applied to D2
before its contents are mapped to schema compnents. The
transformation performs two tasks:
Add a targetNamespaceattribute to D2, whose value
is the same as that of the targetNamespaceattribute of
D1.
Update all QName references in D2 that do not have a namespace name
so that their namespace names become the actual value of the
targetNamespaceattribute.
When a
information item D1 contains
elements, the transformation specified in the following
stylesheet is performed once for
each such element. It requires as
parameters (a) the element in D1
(call it O1) as the overrideElement parameter
and (b)
the element of the schema document D2
identified by the schemaLocation attribute of O1
as the overriddenSchema parameter.
The transformation
produces another D2′, which is equivalent
to D2 except that some elements in D2 are replaced
or modified, as follows.
For each element information item E2 in the children of D2's
, , or
information item,
E2
has element type , ,
, ,
, , or
, and O1 has a child
E1 with the same element type
and the same value for its name
attribute
D2′ has an element identical to E1 in E2's
place.
E2 has one of the
element types specified in ,
but O1 has no
matching child
D2′ has an element identical to E2 in the same
place as where E2 is in D2.
E2 has element type
D2′ has an element
with schemaLocation = E2.schemaLocation
and children identical to those of O1.
E2 has element type
D2′ has an element
O2,
with schemaLocation = E2.schemaLocation
and children which are drawn from among the children of
E2 and O1, as specified by
a child of E2 and a child of O1 match as described
in
O2 has
a child identical to the child of O1.
a child of E2 matches no child of O1 as described
in
(as described in )
O2 has a child identical to the child of E2.
a child of O1 matches no child of E2 as described
in
O2 has a child identical to the child of O1.
Informally, the rule just given has the effect that O2
contains (a) all the children of O1, as well as (b) all of
the children of E2 which are not overridden by some child
of O1. The elements corresponding to children of E2
come first, followed by the children of O1 which matched
nothing in E2.
The base URI of D2′ is the same
as that of D2.
Informally, D2′ is like D2 except that
(a) any elements matched by any children of O1
are overridden (replaced) by the corresponding children of O1,
(b) any schema documents included by means of
elements
in D2 are overridden (transformed) by O1 instead of
being included without change,
and (c) any schema documents overridden by means of
elements
in D2 are to be overridden (transformed) both as
specified in the elements
in D2 and as specified in O1; if both apply,
the information in O1 takes precedence.
The result is that the transformation
described by O1 is applied to all the document in the
of O1.
Because D2 and D2′ have
the same base URI, relative references in D2′ will
be unaffected by the transformation.
Stylesheet for xs:override<xsl:transform version="2.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:f="http://www.w3.org/2008/05/XMLSchema-misc"
exclude-result-prefixes="f">
<xsl:import-schema
namespace="http://www.w3.org/2001/XMLSchema"
schema-location="./XMLSchema.xsd"/>
<xsl:param name="overrideElement" as="schema-element(xs:override)"/>
<xsl:param name="overriddenSchema" as="schema-element(xs:schema)"/>
<xsl:template name="start">
<xsl:result-document validation="strict">
<xsl:apply-templates select="$overriddenSchema"/>
</xsl:result-document>
</xsl:template>
<xsl:template match="schema-element(xs:schema)
| schema-element(xs:redefine)">
<xsl:copy>
<xsl:copy-of select="@*"/>
<xsl:apply-templates/>
</xsl:copy>
</xsl:template>
<xsl:template match="schema-element(xs:import)" priority="5">
<xsl:copy-of select="."/>
</xsl:template>
<!--* replace children of xs:schema, xs:redefine, and xs:override
* which match children of $overrideElement. Retain others.
*-->
<xsl:template match="schema-element(xs:schema)/*
| schema-element(xs:redefine)/*
| schema-element(xs:override)/*"
priority="3">
<xsl:variable name="original" select="."/>
<xsl:variable name="replacement"
select="$overrideElement/*
[node-name(.)=node-name($original)
and
f:componentName(.)=f:componentName($original)]"/>
<xsl:copy-of select="($replacement, $original)[1]"/>
</xsl:template>
<!--* replace xs:include elements with overrides
*-->
<xsl:template match="schema-element(xs:include)"
priority="5">
<xsl:element name="xs:override">
<xsl:copy-of select="@schemaLocation, $overrideElement/*"/>
</xsl:element>
</xsl:template>
<!--* change xs:override elements: children which match
* children of $overrideElement are replaced, others are
* kept, and at the end all children of $overrideElement
* not already inserted are added.
*-->
<xsl:template match="schema-element(xs:override)"
priority="5">
<xsl:element name="xs:override">
<xsl:attribute name="schemaLocation">
<xsl:value-of select="@schemaLocation"/>
</xsl:attribute>
<xsl:apply-templates/>
<xsl:apply-templates select="$overrideElement/*"
mode="copy-unmatched">
<xsl:with-param name="overriddenOverride" select="."/>
</xsl:apply-templates>
</xsl:element>
</xsl:template>
<xsl:template match="*" mode="copy-unmatched">
<xsl:param name="overriddenOverride"></xsl:param>
<xsl:variable name="overriding" select="."/>
<xsl:variable name="overridden" select="$overriddenOverride/*[
node-name(.) = node-name($overriding)
and
f:componentName(.) = f:componentName($overriding)
]"/>
<xsl:choose>
<xsl:when test="count($overridden) > 0">
<!--* do nothing; this element has already been copied *-->
</xsl:when>
<xsl:when test="count($overridden) = 0">
<!--* copy this element, it isn't already there *-->
<xsl:copy-of select="."/>
</xsl:when>
</xsl:choose>
</xsl:template>
<xsl:function name="f:componentName" as="xs:QName">
<xsl:param name="component" as="element()"/>
<xsl:sequence select="
QName($component/ancestor::xs:schema/@targetNamespace,
$component/@name)"/>
</xsl:function>
</xsl:transform>
Changes since version 1.0 (non-normative)
Changes made since version 1.0
The grouping of changes
below is intended to
make the list easier to scan. It is an ad hoc grouping for
convenience to which no great significance should be attached.
Some changes could have been listed in more than one place; in
such cases the choice was arbitrary.
Relationship between XSD and other specifications
Changes to the
relationship between this and other specifications:
Support for XML 1.1 has been added.
It is now implementation defined whether datatypes dependent
on definitions in XML (, ) and Namespaces in XML
(,
) use the definitions as
found in version 1.1 or version 1.0 of those specifications.
To reduce confusion and avert a widespread misunderstanding,
the normative references to various W3C specifications now state
explicitly that while the reference describes the particular edition
of a specification current at the time this specification is
published, conforming implementations of this specification
are not required to ignore later editions of the other
specification but instead may support later editions, thus
allowing users of this specification to benefit from corrections to other
specifications on which this one depends.
XSD versions
Schema language versions:
A conditional inclusion mechanism is defined, roughly
analogous to the XSLT 2.0 use-when attribute or
to the C preprocessor #ifdef construct. By
means of the vc:minVersion and
vc:maxVersion attributes, a simple forward-processing
mechanism is supplied, so that conforming XSD 1.1 processors
can successfully ignore constructs introduced in
future versions (if any) of XSD, and so that schema authors
can define schemas which use newer constructs when available
but can fall back on older constructs when the newer
constructs are not available.
Identifiers for different versions of XSD are now defined
in section .
Changes to content models
Content models:
The
constraint has been relaxed. While competition between two
element particles is still forbidden, as is competition between
two wildcard particles, competition between an and
a is no longer forbidden. In the course of
making this substantive change, some editorial changes have
also been made, in order to make the exposition clearer.
(Readers familiar with version 1.0 of this specification will
find that the constraint works in almost exactly the same way
as it did in 1.0, except that content models in which an input
item matches either a or an are
now allowed.)
Content models may now use the
element to specify content
models with open content. Such content
models allow elements
not explicitly mentioned in
the content model to appear in the document instance; it is
as if wildcards were automatically inserted at appropriate
points within the content model. By specifying what kind of
wildcard is implicitly inserted, the schema author can
adjust the degree of openness and determine what elements
are accepted by the open content; the schema author can also
specify that the content model should be open everywhere, or
only at the end. A schema-document wide default may be
set, which causes all content models to be open unless
otherwise specified.
Wildcards may now be defined which allow names in any
namespace but those in a set of proscribed namespaces.
(In version 1.0 of this specification, only a single
namespace, the target namespace of a schema document,
could be proscribed.) Also, wildcards can now be written
which match any element in a set of namespaces but
which exclude a particular set of qualified names from
matching the wildcard.
Finally,
the keyword ##definedSibling can be used
to exclude all elements explicitly mentioned in
a content model (and all elements substitutable for
those elements).
Wildcards can now be defined which match any element
(in the specified namespaces) which does not
match an element declaration in the schema (so-called
not-in-schema wildcards).
Several of the constraints imposed by version 1.0 of this
specification on all-groups have been relaxed:
Wildcards are now allowed in all groups.
The value of maxOccurs may now be greater than 1 on particles
in an all group. The elements which match a particular
particle need not be adjacent in the input.
all groups can now be extended by adding more members to them.
Complex types whose content models are all-groups
can now be extended; the result is an all-group
(usually a larger one).
The discussion of checking content-type restriction
included in an appendix in earlier drafts of this specification
has now been removed, as have some references to published algorithms
for the problem. Several of the papers referred to are no longer
publicly accessible on the Web, and the changes made to the
have in any case rendered those
algorithms obsolete. These changes resolve issue
6685
Appendix I Checking content-type restriction References Not Available.
Assertions and XPath
Assertions and rules for evaluation of XPaths
Support for check clauses to
implement some co-occurrence constraints has been added. Each
complex type can carry a list of assertions, which are checked
when the complex type is used to validate an element
information item.
The facility for assertions defined in the
working draft of 31 August 2006 has been revised.
The report element described in earlier
drafts has been removed. This involves no loss of functionality:
the same effect can be obtained by wrapping the test expression
on an element in a negation.
The XPath subset defined for assertions has been
eliminated. (A somewhat smaller subset is now defined
for conditional type assignment.)
Rules are defined for the evaluation of XPath expressions
(in assertions, in conditional type assignment, or in
identity-constraint definitions).
The static and dynamic contexts for XPath evaluation
are explicitly specified.
Rules are provided for constructing the data model instance against which the
XPath expressions
are to be evaluated. Different
rules apply in different situations:
When assertions on a complex type are evaluated,
only the subtree rooted in an element of that type is
mapped into the data model instance. References to
ancestor elements or other nodes outside the subtree
are not illegal but will not be effective.
For conditional type assignment, neither the
ancestors nor the children of the element in question
are included; the conditions for type assignment are
thus effectively restricted to the attributes of the
element.
For assertions on simple types, only the value
is provided; the dynamic context includes no
context item.
Rules for assigning types to the nodes of the
data model instance are defined. Again, the rules
differ for the different uses of XPaths:
When assertions are evaluated, all of the elements
and attributes descended from the element being
validated are typed in the normal way; this has the
effect that comparisons among attribute values (for
example) are performed in a way consistent with the
declarations of the attributes. The element node
itself, however, is not typed (since it has not yet
been completely validated).
For conditional type assignment, the nodes of the
data model instance are untyped.
The conceptual overview now included in
some
discussion of the overlap in functionality
among identity constraints, conditional type assignment,
and assertions, and identifies some of the factors
which may be relevant in choosing among them; this
change resolves issue
5023
Relationship between identity constraints and assertions.
The rules for the available collections and default collection
properties of the dynamic context
have been simplified; these properties are now
required to be the empty set instead of being
implementation-defined. This improves interoperability and
resolves issue
6540
Available documents in assertions.
The static context used
for the evaluation of assertions has been clarified; it now
explicitly includes the functions in the
fn namespace and
constructors for all built-in types. This resolves issue
6541
Assertions and in-scope functions.
Derivation of complex types
Derivation of complex types:
The rules for checking validity of complex-type restrictions
have been simplified by reformulating the constraint in terms
of local validity: the set of elements or attributes accepted
by a restriction as locally valid must be a subset of those accepted by its
base type. The rules for attributes have also been changed.
The complex rules involving matching up particles in the base type
and particles in the restriction, with their complex case by
case analysis, have been replaced by a statement of the
constraint which is shorter and more correct.
It is now possible to specify a target namespace for
local elements and attributes which differs from the target
namespace of the schema document itself, when restricting
a complex type which has local elements or attributes and
which itself is in another namespace. This should
simplify the reuse of types from other namespaces.
The rules for complex type restriction now allow identity
constraints on local elements. To make this possible,
identity constraints may now be given names and referred to
from elsewhere. Corresponding changes have been made in the
description of the component and in the
rules for QName
resolution.
This draft clarifies the rule requiring that any complex
type derived by extension could, in principle, be derived in
three steps from xs:anyType (first a restriction step,
then an extension step, then a restriction step). A
misleading note about the purpose of this rule has been
deleted.
Changes to complex type definitions
Complex type definitions (miscellaneous changes):
Changes
have been made to
,
, and
to require more consistency in type
assignment when elements with the same expanded name may
match both a local element declaration and a wildcard
in the same content model.
Conceptually, these
changes are related to
the constraint expressed in
.
XSD 1.0 allows such content
models even if there is a discrepancy between the type
assigned to elements by the local element declarations
and by the top-level element declaration which
will govern elements which match the wildcard.
For compatibility reasons, such content models are still
allowed, but any element instance which matches the wildcard
is required to have a governing type definition compatible with
the type assigned by the local element declarations
matched by the element's expanded name.
The elements and
are now forbidden
to have different values for the mixed
attribute.
Skip wildcards are now excluded from the
constraint, and that
constraint now also takes open content into account; these
changes resolve issue
5940
Element Declarations Consistent.
ID, IDREF, and related types
ID, IDREF, and related types:
Certain constraints involving
ID have been
extended to include lists of ID and unions including
ID. See e.g.
.
An element may now have multiple attributes of type
xs:ID. Elements have always been able to have
multiple children of type xs:ID, but XSD 1.0 forbad
multiple attributes of this type for compatibility
with XML DTDs. (Schemas intended to be translatable into DTD
form should still avoid the practice.) This change should make
it easier for XML vocabularies to support both existing
ID attributes and xml:ID.
The validation rules for values of type xs:IDREF,
xs:ENTITY, or xs:ENTITIES
are now enforced on default values.
Elements and attributes of type xs:ID may now have
default or fixed values. XSD 1.0 had forbidden this, for
compatibility with XML DTDs.
Simple type definitions
Changes involving
simple type definitions and
related constraints:
A new type definition called
anyAtomicType has been introduced into the type
hierarchy between anySimpleType and all the
atomic built-in type definitions. See .
An error in version 1.0 of this
specification relating to the construction of union types from
other union types has been corrected. Unions may now appear
as members of other unions, and all restrictions of unions are
correctly enforced;
the rule has been
modified to ensure that member types are not
for facet-restricted unions.
As a result,
xsi:type may no longer be used, as in XSD 1.0,
to subvert restrictions of union types.
The requirement that a facet value be a valid
restriction of another, in the context of simple
type restriction, has been clarified.
No union type may be a member of its own transitive membership,
nor may any type derived from the union. (XSD 1.0 forbad
union datatypes to be members of other unions and thus had
no need to forbid this explicitly.)
Since not all datatypes have a
defined canonical representation for all of their values,
appeals to the canonical forms of values have been
eliminated.
Changes have been made to ensure that
the descriptions of the component and of xs:anySimpleType agree in all
details with those of .
Equality and identity of lists have been clarified.
The fact that xs:anyType is its own base type
has been clarified (addresses issue
6204
anyType/ur-Type: inconsistent whether it has a base-type).
Element declarations
Changes to element declarations:
A new form of co-occurrence constraint has now been defined,
by allowing the type assigned to element instances to
be conditional on properties of the instance (typically
attribute values). The addition of conditional type assignment
has entailed a number of changes:
Introduction of a property on element declarations,
to hold a sequence of
s (condition - selected-type pairs) and a default
type definition.
Constraints on that table: all types named in the table (including
the default) must be for the
declared .
Changes to the XML syntax and XML mapping rules
to allow expression of conditional type
bindings: the element is added,
the content model of is changed.
Validation rules for conditional types: a validation-time
check on restrictions of complex types ensures that the
conditionally assigned types of their children are appropriately
related to the types assigned by their base type;
see
and
;
the definition of is also adjusted.
Rules for evaluating the conditional typing tests
(more specifically, rules for constructing a temporary infoset
and then building the XDM instance and evaluating the
XPath expressions as defined elsewhere; priority of
tests is given by document order / component order).
PSVI changes to reflect details of the conditional typing:
a {type alternative} property is added, and the discussion of
[type fallback] now refers to the rather than
to either the
declared or to the of the
element information item
Introduction of some terminology for discussing conditional
types
(define ,
conditionally selects,
,
).
Rules for checking type restriction in the presence of conditional
types.
Introduction of a special xs:errortype for use
in identifying conditionally assigned types which violate
restriction rules
Miscellaneous supporting editorial changes.
Element declarations may now specify multiple substitution-group
heads.
Abstract elements may now appear in substitution groups.
The definition of now explicitly
excludesskip wildcards from consideration and makes clear that
xs:anyType never maps an element information item or an
expanded name to any . This
aligns the treatment of type tables more closely with
that of declared types and resolves issue
6561
Type Substitutable in Restriction.
Attribute declarations
Attributes:
Attribute declarations can now be marked
(see )
and the values of inherited attributes are accessible in the XDM
data model instance constructed for conditional type assignment
(see ).
Among other consequences, this allows conditional type assignment
to be sensitive to the inherited value of
the xml:lang attribute and thus to the language of
the element's contents. This change was introduced to resolve issue
5003
Applicability of <alternative> element to xml:lang,
raised by the W3C Internationalization Core Working Group.
The rules for default attribute values now refer to the
effective value constraint,
rather than to the ; this resolves a bug
in the handling of default values for global attribute
declarations.
The text now makes clear that it is pointless (although
not illegal) for schema documents to supply default or fixed
values for xsi:type and other attributes in the
namespace http://www.w3.org/2001/XMLSchema-instance, since they
will not be applied.
Default attribute groups are now supported. The
element can carry a
defaultAttributes attribute, which identifies a
named ; each complex type defined in
the schema document then automatically includes that
attribute group, unless this is overridden by the
defaultAttributesApply attribute on the
element. Default attribute groups
make it easier to specify attributes which should be accepted
by every complex type in a schema (e.g. xml:id
and xml:lang).
All wildcard unions are now expressible;
this change resolves issue
6163
3.10.6.3 Attribute Wildcard Union .
Component structure
Changes in the structure
of schema components:
Every component now has an
{annotations} property whose value is a sequence of annotation
elements and out-of-band attributes. See e.g. .
Annotations are no longer
allowed to vary in the part of a content model shared
by a complex type and its extensions. (This was never
possible in components specified using schema documents,
but was possible in born-binary components.)
A
property has been defined for the definitions of complex and
of simple types; this property simplifies testing for the
identity of anonymous type definitions. See e.g. . The {context} property
replaces the {scope} property found in some earlier drafts of
this document.
The component has an
additional property containing all the identity
constraints in the corresponding schema. See and .
The underlying basis for the
definition of all the different kinds of components has
changed to make use of a regular and formal tabulation of
their properties. This has been achieved by introducing
property records wherever version 1.0 had complex
property values. For example instead of describing the
{scope} property as having "either global or a
complex type definition" for its value, a property record is called for, which in turn has its
own simple properties and values. See e.g. .
The process of validation
The process of validation:
When an xsi:type attribute appears on an element,
and has a QName as its value, but the QName does not resolve to a known
type definition, processors are now required
to fall back to lax validation,
using the declared
of the as the .
Element information items which match no particle in a content
model are now to be validated using their .
Earlier drafts did not specify what happened in such cases.
Lax assessment is now required
when an element information item to be validated has neither
a nor a ; also, lax assessment
now requires that the children and attributes of the element
be assessed as well. In XSD 1.0 and in earlier drafts, lax
assessment was optional and did not require the
recursive assessment of
childrenandattributes.
The text now specifies that if an element has an
xsi:type attribute, the actual value of that attribute
must resolve to a type definition, and that type definition
must be the of the element. (This affects
only elements without a ; other cases were
already handled.)
The terminology of assessment has been changed to avoid the
suggestion that an element information item can be
without being
assessed.
An anomaly in the definition of has been corrected,
to ensure that elements matching strict or lax wildcards have
the appropriate global element declaration, if it exists, as their
. (Resolves issue
7913
Strange result from definition of governing element declaration.)
The usage of the terms validation and
has been clarified, and definitions
of various forms of document validity have been added
for the convenience of users of this specification;
see .
(Resolves issues
5164
validation vs assessment and
6015
[schema11] valid (and its derivations) vs assessment as used in text.)
post-schema-validation infoset
Changes in the
description of the post-schema-validation infoset:
The presentation of the post-schema-validation infoset has been simplified by removing
the suggestion that the post-schema-validation infoset varies from processor to processor.
Instead, the exposition now makes clearer that the body of information
available in principle after schema-validity assessment is consistent
across all
processors; processors may make different subsets of the post-schema-validation infoset
accessible to downstream applications, but when they do so
the variation reflects the implementors' decisions
about what information to expose, not variation in the information
in the post-schema-validation infoset.
Terms have been defined to describe different subsets of the
post-schema-validation infoset which may be exposed by processors.
Provision is made for exposing the
actual values of elements and
attributes in the post-schema-validation infoset, in the
property.
The property and various
other properties in the post-schema-validation infoset are now described as being
present in the post-schema-validation infoset whenever a declaration
and/or type definition is known for the item,
instead of only when the item is valid.
When the type definition of an attribute or element
information item is a list type whose item type is a union,
the post-schema-validation infoset now includes the for
each item in the list.
When default values are supplied for attributes with
qualified names, is performed to ensure that the
in-scope namespaces property of the attribute's host element has an
appropriate binding for the namespace name. It is implementation-defined
whether is also performed on descendants of that element
so as to retain consistency of the infoset. Namespace fixup may also be
helpful if the defaulted value is of type
QName or
NOTATION; it is
implementation-dependent whether fixup is performed for such values.
Annotations given in the XML form of identity-constraint declarations
with ref attributes are now retained in the post-schema-validation infoset
form of the containing element declaration. This change resolves
issue
6144
annotation on IDC with a 'ref' attribute is lost.
Conformance
Changes to the
description of conformance:
The set of conformance classes
has been revised and clarified. Instead of
minimally conforming,
schema-document aware, and
Web-aware processors, this specification
now defines (in section
) conformance classes for
general-purpose validators,
general-purpose schema-validity assessors,
special-purpose validators, and
other special-purpose tools,
together with terminology which may be useful in describing
particular processors.
This change resolves issue
7695
Conformance.
A checklist has been included listing ways in which conforming
processors may vary from each other, and terminology has been
provided for some of the more important properties of conforming
processors, in an attempt to make it easier for implementors to
describe concisely which options their processors exercise, and
easier for users to describe what kinds of processor they
require.
The definition of must and error have been revised to
specify that conforming processors must detect and report
error in the schema or schema documents. The quality
and detail of the error messages are not constrained.
Implementations are now allowed to support primitive datatypes
and facets beyond those defined in .
The validity requirements for schema documents are stated more
fully and correctly.
Schema composition
Schema assembly and composition:
The construct is deprecated.
An construct has been defined;
in some ways it resembles ,
but imposes no constraints on the new definitions provided
for components whose definitions are being overridden.
The discussion of and
has been revised to eliminate an ambiguity in earlier versions of
this spec regarding the meaning of cyclic dependencies formed by
use of and : such
cyclic dependencies are now clearly allowed and have a well defined
meaning.
When an xsi:schemaLocation attribute provides
information about a schema document location for a
particular namespace, it is no longer an error for it to be
encountered after the first occurrence of an element or
attribute information item in that namespace.
Note, however, that if processing such an xsi:schemaLocation
attribute causes new components to be added to the schema, then
the new components cannot change the assessment outcome of any
information items already seen before the element bearing
the xsi:schemaLocation attribute.
No is needed in a schema document
in order to refer to components in namespaces
http://www.w3.org/2001/XMLSchema or http://www.w3.org/2001/XMLSchema-instance.
In XSD 1.0, the examples showed no such imports, but
there was no rule making it legal to omit the .
The handling of chameleon inclusion and redefinition
in schema documents has been simplified. The new target
namespace affects any component or property which would have
the target namespace if the schema document specified one.
This change makes it easier to write assertions in schema
documents without a namespace which are intended to be
included by schema documents with varying target namespaces.
Section has now been added,
defining the terms error and continue
for use in specifying what a processor does or should do
when it seeks components for a given namespace in a given location
but fails to find them there.
Schema processors are now explicitly recommended to provide
a user option to control whether the processor attempts to
dereference schema locations indicated in schemaLocation
attributes in the instance document being validated; this resolves
issue
5476
xsi:schemaLocation should be a hint, should be MAY not SHOULD.
The discussion of schemaLocation information in
has been revised to try to make clearer
the motivation for recommending user control over whether
schema locations specified in the document instance should
or should not be dereferenced. The new text describes some
circumstances in which such schema locations typically should be
dereferenced and some in which they should not, and attempts to
set useful expectations for users and for implementors.
These changes are intended to resolve issue
6655,
raised by the W3C Web Accessibility Initiative's
Protocols and
Formats Working Group.
The discussion of schema import in
now states more
clearly that references to components in external
namespaces are an error if the namespace is not imported;
this change addresses issue
5779
QName resolution and xs:import.
Other substantive changes
Miscellaneous substantive changes:
The discussion of schema-validity assessment and the invocation
of conforming processors has been revised; additional invocation
patterns have been identified, and names have been given to
the different methods of invoking a processor.
When an element cannot be strictly validated because no
element declaration or type definition is available
for it, fallback to lax validation (validating the element
against the built-in type xs:anyType) is now required;
in earlier drafts of this document, fallback to lax validation
was optional.
The XML Representation Constraints no longer refer to the
component level; this makes it possible to test a schema
document in isolation to determine whether it conforms or
fails to conform to these rules.
The constraints on the XML representation of schemas have been
reformulated to allow them to be checked on schema documents in
isolation, rather than requiring knowledge of the rest of the schema
into which they will be embedded. The consequence is that
some errors are caught not in the XML representation constraints
but by having the XML mapping rules generate faulty components
so that the error can be detected at the component level.
These changes resolve issue
6235
Restriction from xs:anySimpleType.
The element is now declared with open
content in the schema for schema documents. This change
addressess issue
5930
defaultOpenContent in the S4SD.
The setting blockDefault="#all" has been removed
from the schema for schema documents; this change resolves issue
6120
Reconsider blockDefault=#all.
Namespace fixup is now explicitly required in some places where
it is needed but was not mentioned before; these changes resolve
issue
6445
Namespace fixup and default namespace and issue
6465
Namespace fixup and inherited attributes.
Clarifications and editorial changes
Clarifications and other
editorial changes:
Each named constraint is now given in a separate section, to
simplify reference to them.
The XML mapping rules have been reorganized to make them
more perspicuous.
The keywords defined by to
designate different levels of requirement have been
marked up to distinguish more
consistently between cases where their normative
meaning is
intended (e.g.
must) and cases where the words are used in
its everyday sense without conformance implications (e.g.
must). See .
A note has been added, warning that
the replace and collapse values
for whitespace handling are not a reliable means of
neutralizing the effects of word-wrapping and pretty-printing
of natural-language data and should not be used for that
purpose.
Several minor corrections and
clarifications have been made. The usage of some technical
terminology has been clarified, normalized, and aligned where
appropriate with the usage in
. Conditionals using
if have been rephrased to use if and
only if where appropriate.
The title of the specification has been changed, and the language
defined here is referred to as XSD, not using the name
XML Schema. This may help reduce confusion between
the language defined here and the broader class of XML schema
languages in general.
Conformance-related language has been reviewed
to avoid confusion between the conformance-related usage of
the verbs may, must, and should, and other usages.
Various new terms have been defined, and some existing terms have
been redefined, to reduce confusion and improve legibility. In
some cases, existing terms which were felt insufficiently
informative have been replaced by new terms which may be more
useful.
Following the example of XQuery
1.0 and XSLT 2.0, the terms implementation-defined and
implementation-dependent have been defined and the two
concepts distinguished. The appendix contains lists both of
implementation-defined and of implementation-dependent features.
The term context-determined-declaration has been
replaced with the term ; this resolves
issue
4690
Editorial: 'context-determined declarations' needs more work.
The namespace prefixes used to refer to well known namespaces
have been changed and are now more consistent; this resolves issue
4316
Make sure namespace prefixes are used appropriately throughout
structures.
Numerous small changes were made in the interests of clarity,
completeness, consistency, and precision, and to correct
typographical errors. These changes
resolve a number of issues, including:
5140
small editorial changes section 3.3;
5148
inconsistent target ns description;
5639
when is value V a valid restriction of value Y?;
5800
Possibly revise list of required infoset properties;
5916
Obsolete editorial note;
5917
Typo in 3.1.1;
5934
Typo concerning <simpleContent mixed="true">;
6011
[schema11] base URI comments;
6156
Typo in 3.4.2;
6162
<anyAttribute> allows ##definedSibling;
6165
Constraints on XML representation of anyAttribute;
6166
Schema Component Model for Wildcards;
6167
Attribute Wildcard Intersection;
6170
Wildcards and defaultAttributes;
6175
Wildcard overlap;
6227
Type Derivation OK (simple); and
6233
Wrong pointer for [nil] PSVI property.
Discussions of global components now
take <redefine> into account (addresses
issue 5918
Top level declarations).
Issues not resolved
It may be useful
to mention some points
where possible changes to the
specification have been discussed, but on which no changes have,
in the end, been made. In some cases, this resulted from the
XML Schema Working Group's determination that no change was
desirable; in other cases, there was no consensus on the
desirability of change, or no consensus on what change should
be made.
As noted above, some restrictions on all groups have
been relaxed; all groups, however, must still be
top-level groups; they are not allowed to appear within
sequences or choice groups.
The namespace-related properties of the basic infoset are
fixed up when
attributes with qualified names are assigned default values.
Other kinds of infoset fixup, however, are still not performed.
Attributes of type ID, IDREF,
IDREFS, and NOTATION do not have
the same effect on the base infoset as they do if declared
in a DTD. (An infoset-to-infoset transformation can be
used to migrate the appropriate information into the base
infoset.)
Some existing implementations (and specifications) assume that
elements of type xs:ID uniquely identify themselves,
instead of uniquely identifying their parent. This version of
this specification reaffirms the existing rule, which is that
elements and attributes of type xs:ID uniquely
identify the parent element of the ID attribute or element.
The identity of components is still underspecified (although
a number of points have been clarified, e.g. by the specification
of the {scope} property), with the
result that some schemas can be interpreted either as conformant
or as non-conformant, depending on the interpretation of
the specification's appeals to component identity.
The constraint
has been recast, but not at the higher level of abstraction
originally required and expected.
The account of schema composition given here has not
eliminated all the uncertainties present in XSD 1.0;
edge cases remain which different conformant implementations
will treat differently.
A systematic tabulation of error conditions and definition of
a new system of error codes was originally foreseen for XSD
1.1, but has not been completed for inclusion here. No further work in this area is
currently anticipated.
Schema Components Diagram (non-normative)
The following UML class diagram shows the
interrelations of element declarations, simple and complex type
definitions, and related component classes. In the interests
of simplicity, a few liberties have been taken with the notation.
For example, direct links are shown from Element Declaration to
Simple Type Definition and Complex Type Definition, rather than
a single link to a generic Type Definition class specialized
by simple and complex types. Similarly, a particle
in a content model has exactly one term, which is either
an element declaration, a wildcard, or a model group, but
this diagram does not show any class created as a generalization
of these three.
The following UML class diagram shows the
relation of various component classes to the
component.
Glossary (non-normative)
The listing below is for the benefit of readers of a printed version of this
document: it collects together all the definitions which appear in the
document above.
An XSL macro is used to
collect definitions from throughout the spec and gather them here for easy
reference.
DTD for Schemas (non-normative)
The DTD for schema documents is given below. Note there is no
implication here that schemamust be the root element of a
document.
Independent copies of this material are
available in an undated (mutable) version at
and in a dated (immutable) version at
— the mutable version will be updated with future revisions of
this specification, and the immutable one will not.
Although this DTD is non-normative, any XML document which is
not valid per this DTD, given redefinitions in its internal subset of the
'p' and 's' parameter entities below appropriate to its namespace
declaration of the XSD namespace, is almost certainly not
a valid schema document, with the exception of documents with multiple namespace
prefixes for the XSD namespace itself. Accordingly
authoring schema documents using this DTD and DTD-based authoring tools, and
specifying it as the DOCTYPE of documents intended to be schema documents and validating them with a validating XML parser, are
sensible development strategies which users are encouraged to adopt
until XSD-based authoring tools and validators are more widely available.
DTD for Schema Documents
<!-- DTD for XML Schema Definition Language Part 1: Structures
Public Identifier: "-//W3C//DTD XMLSCHEMA 200102//EN"
Official Location: http://www.w3.org/2001/XMLSchema.dtd -->
<!-- Id: structures.dtd,v 1.1 2003/08/28 13:30:52 ht Exp -->
<!-- With the exception of cases with multiple namespace
prefixes for the XSD namespace, any XML document which is
not valid per this DTD given redefinitions in its internal subset of the
'p' and 's' parameter entities below appropriate to its namespace
declaration of the XSD namespace is almost certainly not
a valid schema document. -->
<!-- See below (at the bottom of this document) for information about
the revision and namespace-versioning policy governing this DTD. -->
<!-- The simpleType element and its constituent parts
are defined in XML Schema Definition Language Part 2: Datatypes -->
<!ENTITY % xs-datatypes PUBLIC 'datatypes' 'datatypes.dtd' >
<!ENTITY % p 'xs:'> <!-- can be overridden in the internal subset of a
schema document to establish a different
namespace prefix -->
<!ENTITY % s ':xs'> <!-- if %p is defined (e.g. as foo:) then you must
also define %s as the suffix for the appropriate
namespace declaration (e.g. :foo) -->
<!ENTITY % nds 'xmlns%s;'>
<!-- Define all the element names, with optional prefix -->
<!ENTITY % schema "%p;schema">
<!ENTITY % defaultOpenContent "%p;defaultOpenContent">
<!ENTITY % complexType "%p;complexType">
<!ENTITY % complexContent "%p;complexContent">
<!ENTITY % openContent "%p;openContent">
<!ENTITY % simpleContent "%p;simpleContent">
<!ENTITY % extension "%p;extension">
<!ENTITY % element "%p;element">
<!ENTITY % alternative "%p;alternative">
<!ENTITY % unique "%p;unique">
<!ENTITY % key "%p;key">
<!ENTITY % keyref "%p;keyref">
<!ENTITY % selector "%p;selector">
<!ENTITY % field "%p;field">
<!ENTITY % group "%p;group">
<!ENTITY % all "%p;all">
<!ENTITY % choice "%p;choice">
<!ENTITY % sequence "%p;sequence">
<!ENTITY % any "%p;any">
<!ENTITY % anyAttribute "%p;anyAttribute">
<!ENTITY % attribute "%p;attribute">
<!ENTITY % attributeGroup "%p;attributeGroup">
<!ENTITY % include "%p;include">
<!ENTITY % import "%p;import">
<!ENTITY % redefine "%p;redefine">
<!ENTITY % override "%p;override">
<!ENTITY % notation "%p;notation">
<!ENTITY % assert "%p;assert">
<!-- annotation elements -->
<!ENTITY % annotation "%p;annotation">
<!ENTITY % appinfo "%p;appinfo">
<!ENTITY % documentation "%p;documentation">
<!-- Customisation entities for the ATTLIST of each element type.
Define one of these if your schema takes advantage of the
anyAttribute='##other' in the schema for schema documents -->
<!ENTITY % schemaAttrs ''>
<!ENTITY % defaultOpenContentAttrs ''>
<!ENTITY % complexTypeAttrs ''>
<!ENTITY % complexContentAttrs ''>
<!ENTITY % openContentAttrs ''>
<!ENTITY % simpleContentAttrs ''>
<!ENTITY % extensionAttrs ''>
<!ENTITY % elementAttrs ''>
<!ENTITY % groupAttrs ''>
<!ENTITY % allAttrs ''>
<!ENTITY % choiceAttrs ''>
<!ENTITY % sequenceAttrs ''>
<!ENTITY % anyAttrs ''>
<!ENTITY % anyAttributeAttrs ''>
<!ENTITY % attributeAttrs ''>
<!ENTITY % attributeGroupAttrs ''>
<!ENTITY % uniqueAttrs ''>
<!ENTITY % keyAttrs ''>
<!ENTITY % keyrefAttrs ''>
<!ENTITY % selectorAttrs ''>
<!ENTITY % fieldAttrs ''>
<!ENTITY % assertAttrs ''>
<!ENTITY % includeAttrs ''>
<!ENTITY % importAttrs ''>
<!ENTITY % redefineAttrs ''>
<!ENTITY % overrideAttrs ''>
<!ENTITY % notationAttrs ''>
<!ENTITY % annotationAttrs ''>
<!ENTITY % appinfoAttrs ''>
<!ENTITY % documentationAttrs ''>
<!ENTITY % complexDerivationSet "CDATA">
<!-- #all or space-separated list drawn from derivationChoice -->
<!ENTITY % blockSet "CDATA">
<!-- #all or space-separated list drawn from
derivationChoice + 'substitution' -->
<!ENTITY % mgs '%all; | %choice; | %sequence;'>
<!ENTITY % cs '%choice; | %sequence;'>
<!ENTITY % formValues '(qualified|unqualified)'>
<!ENTITY % attrDecls '((%attribute;| %attributeGroup;)*,(%anyAttribute;)?)'>
<!ENTITY % assertions '(%assert;)*'>
<!ENTITY % particleAndAttrs '(%openContent;?, (%mgs; | %group;)?,
%attrDecls;, %assertions;)'>
<!-- This is used in part2 -->
<!ENTITY % restriction1 '((%mgs; | %group;)?)'>
%xs-datatypes;
<!-- the duplication below is to produce an unambiguous content model
which allows annotation everywhere -->
<!ELEMENT %schema; ((%include; | %import; | %redefine; | %override; | %annotation;)*,
(%defaultOpenContent;, (%annotation;)*)?,
((%simpleType; | %complexType;
| %element; | %attribute;
| %attributeGroup; | %group;
| %notation; ),
(%annotation;)*)* )>
<!ATTLIST %schema;
targetNamespace %URIref; #IMPLIED
version CDATA #IMPLIED
%nds; %URIref; #FIXED 'http://www.w3.org/2001/XMLSchema'
xmlns CDATA #IMPLIED
finalDefault %complexDerivationSet; ''
blockDefault %blockSet; ''
id ID #IMPLIED
elementFormDefault %formValues; 'unqualified'
attributeFormDefault %formValues; 'unqualified'
defaultAttributes CDATA #IMPLIEDxpathDefaultNamespace CDATA '##local'
xml:lang CDATA #IMPLIED
%schemaAttrs;>
<!-- Note the xmlns declaration is NOT in the schema for schema documents,
because at the Infoset level where schemas operate,
xmlns(:prefix) is NOT an attribute! -->
<!-- The declaration of xmlns is a convenience for schema authors -->
<!-- The id attribute here and below is for use in external references
from non-schemas using simple fragment identifiers.
It is NOT used for schema-to-schema reference, internal or
external. -->
<!ELEMENT %defaultOpenContent; ((%annotation;)?, %any;)>
<!ATTLIST %defaultOpenContent;
appliesToEmpty (true|false) 'false'
mode (interleave|suffix) 'interleave'
id ID #IMPLIED
%defaultOpenContentAttrs;>
<!-- a type is a named content type specification which allows attribute
declarations-->
<!-- -->
<!ELEMENT %complexType; ((%annotation;)?,
(%simpleContent;|%complexContent;|
%particleAndAttrs;))>
<!ATTLIST %complexType;
name %NCName; #IMPLIED
id ID #IMPLIED
abstract %boolean; #IMPLIED
final %complexDerivationSet; #IMPLIED
block %complexDerivationSet; #IMPLIED
mixed (true|false) 'false'
defaultAttributesApply %boolean; 'true'
%complexTypeAttrs;>
<!-- particleAndAttrs is shorthand for a root type -->
<!-- mixed is disallowed if simpleContent, overridden if complexContent has one too. -->
<!-- If anyAttribute appears in one or more referenced attributeGroups
and/or explicitly, the intersection of the permissions is used -->
<!ELEMENT %complexContent; ((%annotation;)?, (%restriction;|%extension;))>
<!ATTLIST %complexContent;
mixed (true|false) #IMPLIED
id ID #IMPLIED
%complexContentAttrs;>
<!ELEMENT %openContent; ((%annotation;)?, (%any;)?)>
<!ATTLIST %openContent;
mode (none|interleave|suffix) 'interleave'
id ID #IMPLIED
%openContentAttrs;>
<!-- restriction should use the branch defined above, not the simple
one from part2; extension should use the full model -->
<!ELEMENT %simpleContent; ((%annotation;)?, (%restriction;|%extension;))>
<!ATTLIST %simpleContent;
id ID #IMPLIED
%simpleContentAttrs;>
<!-- restriction should use the simple branch from part2, not the
one defined above; extension should have no particle -->
<!ELEMENT %extension; ((%annotation;)?, (%particleAndAttrs;))>
<!ATTLIST %extension;
base %QName; #REQUIRED
id ID #IMPLIED
%extensionAttrs;>
<!-- an element is declared by either:
a name and a type (either nested or referenced via the type attribute)
or a ref to an existing element declaration -->
<!ELEMENT %element; ((%annotation;)?, (%complexType;| %simpleType;)?,
(%alternative;)*,
(%unique; | %key; | %keyref;)*)>
<!-- simpleType or complexType only if no type|ref attribute -->
<!-- ref not allowed at top level -->
<!ATTLIST %element;
name %NCName; #IMPLIED
id ID #IMPLIED
ref %QName; #IMPLIED
type %QName; #IMPLIED
minOccurs %nonNegativeInteger; #IMPLIED
maxOccurs CDATA #IMPLIED
nillable %boolean; #IMPLIED
substitutionGroup %QName; #IMPLIED
abstract %boolean; #IMPLIED
final %complexDerivationSet; #IMPLIED
block %blockSet; #IMPLIED
default CDATA #IMPLIED
fixed CDATA #IMPLIED
form %formValues; #IMPLIED
targetNamespace %URIref; #IMPLIED
%elementAttrs;>
<!-- type and ref are mutually exclusive.
name and ref are mutually exclusive, one is required -->
<!-- In the absence of type AND ref, type defaults to type of
substitutionGroup, if any, else xs:anyType, i.e. unconstrained -->
<!-- default and fixed are mutually exclusive -->
<!ELEMENT %alternative; ((%annotation;)?,
(%simpleType; | %complexType;)?) >
<!ATTLIST %alternative;
test CDATA #IMPLIED
type %QName; #IMPLIED
xpathDefaultNamespace CDATA #IMPLIED
id ID #IMPLIED >
<!ELEMENT %group; ((%annotation;)?,(%mgs;)?)>
<!ATTLIST %group;
name %NCName; #IMPLIED
ref %QName; #IMPLIED
minOccurs %nonNegativeInteger; #IMPLIED
maxOccurs CDATA #IMPLIED
id ID #IMPLIED
%groupAttrs;>
<!ELEMENT %all; ((%annotation;)?, (%element;| %group;| %any;)*)>
<!ATTLIST %all;
minOccurs (0 | 1) #IMPLIED
maxOccurs (0 | 1) #IMPLIED
id ID #IMPLIED
%allAttrs;>
<!ELEMENT %choice; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)>
<!ATTLIST %choice;
minOccurs %nonNegativeInteger; #IMPLIED
maxOccurs CDATA #IMPLIED
id ID #IMPLIED
%choiceAttrs;>
<!ELEMENT %sequence; ((%annotation;)?, (%element;| %group;| %cs; | %any;)*)>
<!ATTLIST %sequence;
minOccurs %nonNegativeInteger; #IMPLIED
maxOccurs CDATA #IMPLIED
id ID #IMPLIED
%sequenceAttrs;>
<!-- an anonymous grouping in a model, or
a top-level named group definition, or a reference to same -->
<!ELEMENT %any; (%annotation;)?>
<!ATTLIST %any;
namespace CDATA #IMPLIED
notNamespace CDATA #IMPLIED
notQName CDATA ''
processContents (skip|lax|strict) 'strict'
minOccurs %nonNegativeInteger; '1'
maxOccurs CDATA '1'
id ID #IMPLIED
%anyAttrs;>
<!-- namespace is interpreted as follows:
##any - - any non-conflicting WFXML at all
##other - - any non-conflicting WFXML from namespace other
than targetNamespace
##local - - any unqualified non-conflicting WFXML/attribute
one or - - any non-conflicting WFXML from
more URI the listed namespaces
references
##targetNamespace ##local may appear in the above list,
with the obvious meaning -->
<!-- notNamespace is interpreted as follows:
##local - - any unqualified non-conflicting WFXML/attribute
one or - - any non-conflicting WFXML from
more URI the listed namespaces
references
##targetNamespace ##local may appear in the above list,
with the obvious meaning -->
<!ELEMENT %anyAttribute; (%annotation;)?>
<!ATTLIST %anyAttribute;
namespace CDATA #IMPLIED
notNamespace CDATA #IMPLIED
notQName CDATA ''
processContents (skip|lax|strict) 'strict'
id ID #IMPLIED
%anyAttributeAttrs;>
<!-- namespace and notNamespace are interpreted as for 'any' above -->
<!-- simpleType only if no type|ref attribute -->
<!-- ref not allowed at top level, name iff at top level -->
<!ELEMENT %attribute; ((%annotation;)?, (%simpleType;)?)>
<!ATTLIST %attribute;
name %NCName; #IMPLIED
id ID #IMPLIED
ref %QName; #IMPLIED
type %QName; #IMPLIED
use (prohibited|optional|required) #IMPLIED
default CDATA #IMPLIED
fixed CDATA #IMPLIED
form %formValues; #IMPLIED
targetNamespace %URIref; #IMPLIEDinheritable %URIref; #IMPLIED
%attributeAttrs;>
<!-- type and ref are mutually exclusive.
name and ref are mutually exclusive, one is required -->
<!-- default for use is optional when nested, none otherwise -->
<!-- default and fixed are mutually exclusive -->
<!-- type attr and simpleType content are mutually exclusive -->
<!-- an attributeGroup is a named collection of attribute decls, or a
reference thereto -->
<!ELEMENT %attributeGroup; ((%annotation;)?,
(%attribute; | %attributeGroup;)*,
(%anyAttribute;)?) >
<!ATTLIST %attributeGroup;
name %NCName; #IMPLIED
id ID #IMPLIED
ref %QName; #IMPLIED
%attributeGroupAttrs;>
<!-- ref iff no content, no name. ref iff not top level -->
<!-- better reference mechanisms -->
<!ELEMENT %unique; ((%annotation;)?, %selector;, (%field;)+)>
<!ATTLIST %unique;
name %NCName; #IMPLIED
ref %QName; #IMPLIED
id ID #IMPLIED
%uniqueAttrs;>
<!ELEMENT %key; ((%annotation;)?, %selector;, (%field;)+)>
<!ATTLIST %key;
name %NCName; #IMPLIED
ref %QName; #IMPLIED
id ID #IMPLIED
%keyAttrs;>
<!ELEMENT %keyref; ((%annotation;)?, %selector;, (%field;)+)>
<!ATTLIST %keyref;
name %NCName; #IMPLIED
ref %QName; #IMPLIED
refer %QName; #IMPLIED
id ID #IMPLIED
%keyrefAttrs;>
<!ELEMENT %selector; ((%annotation;)?)>
<!ATTLIST %selector;
xpath %XPathExpr; #REQUIRED
xpathDefaultNamespace CDATA #IMPLIED
id ID #IMPLIED
%selectorAttrs;>
<!ELEMENT %field; ((%annotation;)?)>
<!ATTLIST %field;
xpath %XPathExpr; #REQUIRED
xpathDefaultNamespace CDATA #IMPLIED
id ID #IMPLIED
%fieldAttrs;>
<!-- co-constraint assertions -->
<!ELEMENT %assert; ((%annotation;)?)>
<!ATTLIST %assert;
test %XPathExpr; #REQUIRED
id ID #IMPLIED
xpathDefaultNamespace CDATA #IMPLIED
%assertAttrs;>
<!-- Schema combination mechanisms -->
<!ELEMENT %include; (%annotation;)?>
<!ATTLIST %include;
schemaLocation %URIref; #REQUIRED
id ID #IMPLIED
%includeAttrs;>
<!ELEMENT %import; (%annotation;)?>
<!ATTLIST %import;
namespace %URIref; #IMPLIED
schemaLocation %URIref; #IMPLIED
id ID #IMPLIED
%importAttrs;>
<!ELEMENT %redefine; (%annotation; | %simpleType; | %complexType; |
%attributeGroup; | %group;)*>
<!ATTLIST %redefine;
schemaLocation %URIref; #REQUIRED
id ID #IMPLIED
%redefineAttrs;>
<!ELEMENT %override; ((%annotation;)?,
((%simpleType; | %complexType; | %group; | %attributeGroup;) |
%element; | %attribute; | %notation;)*)>
<!ATTLIST %override;
schemaLocation %URIref; #REQUIRED
id ID #IMPLIED
%overrideAttrs;>
<!ELEMENT %notation; (%annotation;)?>
<!ATTLIST %notation;
name %NCName; #REQUIRED
id ID #IMPLIED
public CDATA #REQUIRED
system %URIref; #IMPLIED
%notationAttrs;>
<!-- Annotation is either application information or documentation -->
<!-- By having these here they are available for datatypes as well
as all the structures elements -->
<!ELEMENT %annotation; (%appinfo; | %documentation;)*>
<!ATTLIST %annotation; %annotationAttrs;>
<!-- User must define annotation elements in internal subset for this
to work -->
<!ELEMENT %appinfo; ANY> <!-- too restrictive -->
<!ATTLIST %appinfo;
source %URIref; #IMPLIED
id ID #IMPLIED
%appinfoAttrs;>
<!ELEMENT %documentation; ANY> <!-- too restrictive -->
<!ATTLIST %documentation;
source %URIref; #IMPLIED
id ID #IMPLIED
xml:lang CDATA #IMPLIED
%documentationAttrs;>
<!NOTATION XMLSchemaStructures PUBLIC
'structures' 'http://www.w3.org/2001/XMLSchema.xsd' >
<!NOTATION XML PUBLIC
'REC-xml-1998-0210' 'http://www.w3.org/TR/1998/REC-xml-19980210' >
<!--
In keeping with the XML Schema WG's standard versioning policy,
this DTD will persist at the URI
.
At the date of issue it can also be found at the URI
.
The schema document at that URI may however change in the future,
in order to remain compatible with the latest version of XSD
and its namespace. In other words, if XSD or the XML Schema
namespace change, the version of this document at
will change accordingly;
the version at
will not change.
Previous dated (and unchanging) versions of this DTD include:
http://www.w3.org/2009/04/structures.dtd
(XSD 1.1 Candidate Recommendation)
http://www.w3.org/2004/10/structures.dtd
(XSD 1.0 Recommendation, Second Edition)
http://www.w3.org/2001/05/structures.dtd
(XSD 1.0 Recommendation, First Edition)
-->
Analysis of the Unique Particle Attribution Constraint (non-normative)
A specification of the import of which does
not appeal to a processing model is difficult. What follows is intended as
guidance, without claiming to be complete.
Two non-group
particles overlap if
They are both element declaration particles whose declarations have the
same expanded name.
or
They are both element declaration particles
and one of them has the sameexpanded name
as
an element declaration in the
other's substitution group.
or
They are both global element declaration particles and their
substitution groups contain the same
element declaration.
or
They are both wildcards, and any one of the following is true of the wildcard intersection of their s as defined
in :
It has = any.
It has = not.
It has = enumeration and ≠ the empty set.
A content model will violate the unique attribution constraint if it
contains two particles which overlap and which either
are both in the of a choice or
all group
or
may validate adjacent information items and the first has
less than .
Two particles may validate adjacent information items if they are
separated by at most epsilon transitions in the most obvious transcription of a
content model into a finite-state automaton.
A precise formulation of this constraint can also be offered in terms of
operations on finite-state automaton: transcribe the content model into an
automaton in the usual way using epsilon transitions for optionality and
unbounded maxOccurs, unfolding other numeric occurrence ranges and treating the heads of substitution groups as if
they were choices over all elements in the group, but using not
element QNames as transition labels, but rather pairs of element QNames and
positions in the model. Determinize this automaton, treating wildcard transitions as
if
they were distinct from all other edge labels for the purposes of the
determinization. Now replace all
QName+position transition labels with the element QNames alone. If the result has any states
with two or more identical-QName-labeled transitions from it, or two
wildcard transitions whose intentional intersection is non-empty, the model does not
satisfy the Unique Attribution constraint.
XSD Language Identifiers (non-normative)
XSD
XSD 1.0
XSD 1.1
XSD 1.0 First Edition
XSD 1.0 Second Edition
XSD 1.1 First Edition
XSD 1.0 in 6 May 1999 working draft
XSD 1.0 in 24 September 1999 working draft
XSD 1.0 in 5 November 1999 working draft
XSD 1.0 in 17 December 1999 working draft
XSD 1.0 in 25 February 2000 working draft
XSD 1.0 in 7 April 2000 working draft
XSD 1.0 in 22 September 2000 working draft
XSD 1.0 Candidate Recommendation (CR)
XSD 1.0 first Proposed Recommendation (PR)
XSD 1.0 second Proposed Recommendation (PR)
XSD 1.0 Recommendation
XSD 1.0 Second Edition Proposed Edited Recommendation (PER)
XSD 1.0 Second Edition Recommendation
XSD 1.1 in 16 July 2004 working draft
XSD 1.1 in 24 February 2005 working draft
XSD 1.1 in 16 January 2006 working draft
XSD 1.1 in 17 February 2006 working draft
XSD 1.1 in 30 March 2006 working draft
XSD 1.1 in 31 August 2006 working draft
XSD 1.1 in 30 August 2007 working draft
XSD 1.1 in 20 June 2008 working draft
XSD 1.1 in 30 January 2009 working draft
XSD 1.1 Candidate Recommendation, 30 April 2009
References
Normative
World Wide Web Consortium.XQuery 1.0 and XPath 2.0 Functions and Operators,
ed. Ashok Malhotra, Jim Melton, and Norman Walsh.W3C Recommendation23 January 2007. See
http://www.w3.org/TR/xpath-functions/
The edition cited is the one current at the date of publication of this
specification. Implementations may follow the edition cited and/or
any later edition(s); it is implementation-defined which.
Bradner, Scott.RFC
2119: Key words for use in RFCs to Indicate Requirement Levels.
IETF (Internet Engineering Task Force), 1997. See http://www.ietf.org/rfc/rfc2119.txt.World Wide Web Consortium.XQuery 1.0 and XPath 2.0 Data Model (XDM),
ed. Mary Fernández et al.W3C Recommendation
23 January 2007. See
http://www.w3.org/TR/xpath-datamodel/
The edition cited is the one current at the date of publication of this
specification. Implementations may follow the edition cited and/or
any later edition(s); it is implementation-defined which.
World Wide Web Consortium.Extensible Markup Language (XML) 1.0 (Fifth Edition),
ed. Tim Bray et al.
W3C Recommendation 26 November 2008.Available at
http://www.w3.org/TR/xml/
The edition cited is the one current at the date of publication of this
specification. Implementations may follow the edition cited and/or
any later edition(s); it is implementation-defined which.
For details of the dependency of this specification on XML 1.1,
see .World Wide Web Consortium.Extensible Markup Language (XML) 1.1
(Second Edition),
ed. Tim Bray et al.
W3C Recommendation 16 August 2006,
edited in place 29 September 2006. Available athttp://www.w3.org/TR/xml11/
The edition cited is the one current at the date of publication of this
specification. Implementations may follow the edition cited and/or
any later edition(s); it is implementation-defined which.
For
details of the dependency of this specification on XML
1.1, see . World Wide Web Consortium.XML Information Set
(Second Edition),
ed. John Cowan and Richard Tobin
W3C Recommendation 4 February 2004.Available at
http://www.w3.org/TR/xml-infoset/
The edition cited is the one current at the date of publication of this
specification. Implementations may follow the edition cited and/or
any later edition(s); it is implementation-defined which.
World Wide Web Consortium.Namespaces in XML1.0 (Second Edition),
ed. Tim Bray et al.
W3C Recommendation 16 August 2006.
See http://www.w3.org/TR/xml-names/
The edition cited is the one current at the date of publication of this
specification. Implementations may follow the edition cited and/or
any later edition(s); it is implementation-defined which.
For details of the
dependency of this specification on Namespaces in XML 1.0, see
.
World Wide Web Consortium.
Namespaces in XML 1.1
(Second Edition),
ed. Tim Bray et al.
W3C Recommendation 16 August 2006.
Available at: http://www.w3.org/TR/xml-names11/
The edition cited is the one current at the date of publication of this
specification. Implementations may follow the edition cited and/or
any later edition(s); it is implementation-defined which.
For details of the dependency of this
specification on Namespaces in XML 1.1, see . World Wide Web Consortium.XML Schema
Version 1.1
Part 2: Datatypes,
ed.Dave Peterson,Paul V. Biron and
Ashok Malhotra,
and C. M. Sperberg-McQueenW3C Working Draft 3 December 2009.
See http://www.w3.org/TR/2009/WD-xmlschema11-2-20091203/datatypes.html
The edition cited is the one current at the date of publication of this
specification. Implementations may follow the edition cited and/or
any later edition(s); it is implementation-defined which.
World Wide Web Consortium.XML Schema Part 1: Structures,
ed. Henry S. Thompson et al.
W3C Recommendation 28 October 2004.
See http://www.w3.org/TR/xmlschema-1/.
The edition cited is the one current at the date of publication of this
specification. Implementations may follow the edition cited and/or
any later edition(s); it is implementation-defined which.
World Wide Web Consortium.XML Path Language 2.0,
ed. Anders Berglund et al.23 January 2007.
See http://www.w3.org/TR/xpath20/
The edition cited is the one current at the date of publication of this
specification. Implementations may follow the edition cited and/or
any later edition(s); it is implementation-defined which.
World Wide Web Consortium.XSL Transformations (XSLT) Version 2.0,
ed. Michael Kay.
23 January 2007.
See http://www.w3.org/TR/xslt20/
The edition cited is the one current at the date of publication of this
specification. Implementations may follow the edition cited and/or
any later edition(s); it is implementation-defined which.
Non-normative
Brüggemann-Klein, Anne, and
Derick Wood.One-Unambiguous Regular Languages.Information and Computation
140 (1998): 229-253.
Also appears as 142 (1998): 182-206.
Chamberlin, Don.Impact of precisionDecimal on XPath and XQuery
Email to the W3C XML Query and W3C XSL Working
Groups, 16 May 2006. Available online at http://www.w3.org/XML/2007/dc.pd.xml and http://www.w3.org/XML/2007/dc.pd.htmlBray, Tim, Charles Frankston, and Ashok Malhotra, ed.,Document Content Description
for XML (DCD).Submission to the World Wide Web Consortium 31-July-1998.[A submission to W3C from International Business Machines
Corporation and Microsoft Corporation.]
See http://www.w3.org/TR/1998/NOTE-dcd-19980731Bourret, Ronald, et al., ed.,Document Definition Markup Language
(DDML) Specification, Version 1.0.W3C Note, 19-Jan-1999.[A submission to W3C from
GMD - Forschungszentrum Informationstechnik GmbH.]
See http://www.w3.org/TR/1999/NOTE-ddml-19990119
World Wide Web Consortium.Requirements for XML
Schema 1.1, ed. Charles Campbell, Ashok Malhotra, and
Priscilla Walmsley. W3C, 21 January 2003. See http://www.w3.org/TR/xmlschema-11-req/The Rule of Least Power,
ed. Tim Berners-Lee
and Noah Mendelsohn.
W3C TAG Finding 23 February 2006.
See http://www.w3.org/2001/tag/doc/leastPower.html.
Marinelli, Paolo, Claudio Sacerdoti Coen, and Fabio Vitali.SchemaPath, a
Minimal Extension to XML Schema for Conditional Constraints.
In Proceedings of the Thirteenth International World
Wide Web Conference, New York: ACM Press, 2004,
pp. 164-174.
Available on the Web in the ACM Digital Library; citation at
http://portal.acm.org/citation.cfm?doid=988672.988695.
Fuchs, Matthew, Murray Maloney, and Alex Milowski.Schema for Object-oriented XML.
Submitted to W3C 19980915.[A submission to W3C by Veo Systems Inc.]See
http://www.w3.org/TR/1998/NOTE-SOX-19980930/Davidson, Andrew, et al.Schema for Object-oriented XML 2.0.
See http://www.w3.org/TR/NOTE-SOX/World Wide Web Consortium.User Agent Accessibility Guidelines 1.0,
ed. Ian Jacobs,
Jon Gunderson, and
Eric Hansen.
W3C Recommendation 17 December 2002.
See http://www.w3.org/TR/UAAG10/.
World Wide Web Consortium.User Agent Accessibility Guidelines (UAAG) 2.0,
ed. James Allan, Jan Richards, and
Jeanne Spellman.
W3C Working Draft 11 March 2009.
See http://www.w3.org/TR/UAAG20/.
Frankston, Charles, and Henry S. Thompson.XML-Data Reduced,
3 July 1998.
[This note is a refinement of
the January 1998 XML-Data submission
http://www.w3.org/TR/1998/NOTE-XML-data-0105/.]
See http://www.ltg.ed.ac.uk/~ht/XMLData-Reduced.htm
Layman, Andrew, et al.XML-Data.
W3C Note 05 Jan 1998.[A submission to W3C by
Microsoft, ArborText, DataChannel, and Inso.]
See http://www.w3.org/TR/1998/NOTE-XML-data-0105/World Wide Web Consortium.XML Schema: Component Designators, ed. Mary
Holstege and Asir Vedamuthu.
W3C Working Draft 17 November 2008.
See http://www.w3.org/TR/xmlschema-ref/.
World Wide Web Consortium.XML Schema Part 0: Primer
Second Edition,
ed.Priscilla Walmsley and
and David C. Fallside.W3C Recommendation 28 October 2004.
See http://www.w3.org/TR/xmlschema-0/World Wide Web Consortium.XML Schema Requirements ,
ed. Ashok Malhotra and Murray Maloney
W3C
Note 15 February 1999.
See http://www.w3.org/TR/NOTE-xml-schema-reqWorld Wide Web Consortium.XML Path Language,
ed. James Clark and Steve DeRose
W3C Recommendation 16 November 1999.
See http://www.w3.org/TR/xpathWorld Wide Web Consortium.XPointer Framework,
ed. Paul Grosso et al.
W3C Recommendation 25 March 2003. See
http://www.w3.org/TR/xptr-framework/
Acknowledgements (non-normative)
The following contributed material to version 1.0 of this specification:
David Fallside, IBMScott Lawrence, Agranat SystemsAndrew Layman, MicrosoftEve L. Maler, Sun MicrosystemsAsir S. Vedamuthu, webMethods, Inc
The Working Group thanks the members of other W3C Working
Groups and industry experts in other forums who have contributed
directly or indirectly to the creation of this document and its
predecessor.
The work of C. M. Sperberg-McQueen
as a co-editor of this specification was supported by the World
Wide Web Consortium through January 2009, and beginning in
February 2009 by Black Mesa Technologies LLC.
At the time this Working Draft is published, the members
in good standing of the XML Schema Working Group are:
Paul V. BironInvited expertDavid EzellNational Association of Convenience Stores (NACS)chairShudi (Sandy) Gao 高殊镝IBMMary HolstegeMark LogicMichael KayInvited expertPaolo MarinelliUniversity of BolognaNoah MendelsohnIBMDave PetersonInvited expertC. M. Sperberg-McQueeninvited expertHenry S. ThompsonUniversity of Edinburgh and W3Cstaff contactScott TsaoThe Boeing CompanyFabio VitaliUniversity of BolognaStefano ZacchiroliUniversity of Bologna
The XML Schema Working Group has benefited in its work from the
participation and contributions of a number of people who are no
longer members of the Working Group in good standing at the time
of publication of this Working Draft. Their names are given below.
In particular we note
with sadness the accidental death of Mario Jeckle shortly before
publication of the first Working Draft of XML Schema 1.1.
Affiliations given are (among) those current at the time of the
individuals' work with the WG.
Paula AngersteinVignette CorporationLeonid ArbouzovSun MicrosystemsJim BarnetteDefense Information Systems Agency (DISA)David BeechOracle Corp.Gabe Beged-DovRogue Wave SoftwareLaila BenhlimaEcole Mohammadia d'Ingenieurs Rabat (EMI)Doris BernardiniDefense Information Systems Agency (DISA)Don BoxDevelopMentorAllen BrownMicrosoftLee BuckTIBCO ExtensibilityGreg BumgardnerRogue Wave SoftwareDean BursonLotus Development CorporationCharles E. CampbellInvited expertOriol CarboUniversity of EdinburghWayne CarrIntelPeter ChenBootstrap Alliance and LSUTyng-Ruey ChuangAcademia SinicaTony CincottaNISTDavid ClearyProgress SoftwareMike CokusMITREDan ConnollyW3Cstaff contactUgo CordaXeroxRoger L. CostelloMITREJoey CoyleHealth Level SevenHaavard DanielsonProgress SoftwareJosef DietlMozquito TechnologiesKenneth DolsonDefense Information Systems Agency (DISA)Andrew EisenbergProgress SoftwareRob EllmanCalico CommerceTim EwaldDevelopmentorAlexander FalkAltova GmbHDavid FallsideIBMGeorge FeinbergObject DesignDan FoxDefense Logistics Information Service (DLIS)Charles FrankstonMicrosoftMatthew FuchsCommerce OneAndrew GoodchildDistributed Systems Technology Centre (DSTC Pty Ltd)Xan GreggTIBCO ExtensibilityPaul GrossoArbortext, IncMartin GudginDevelopMentorErnesto GuerrieriInsoDave HollanderHewlett-Packard Companyco-chairNelson HungCorelJane HunterDistributed Systems Technology Centre (DSTC Pty Ltd)Michael HymanMicrosoftRenato IannellaDistributed Systems Technology Centre (DSTC Pty Ltd)Mario JeckleDaimlerChryslerRick JelliffeAcademia SinicaMarcel JemioData Interchange Standards AssociationSimon JohnstonRational SoftwareKohsuke KawaguchiSun MicrosystemsDianne KennedyGraphic Communications AssociationJanet KoenigSun MicrosystemsSetrag KhoshafianTechnology Deployment International (TDI)Melanie KudelaUniform Code CouncilAra KullukianTechnology Deployment International (TDI)Andrew LaymanMicrosoftDmitry LenkovHewlett-Packard CompanyBob LojekMozquito TechnologiesJohn McCarthyLawrence Berkeley National LaboratoryMatthew MacKenzieXML GlobalEve MalerSun MicrosystemsAshok MalhotraIBM, Microsoft, OracleMurray MaloneyMuzmo Communication, acting for Commerce OneLisa MartinIBMJim MeltonOracle CorpAdrian MichelCommerce OneAlex MilowskiInvited expertDon MullenTIBCO ExtensibilityRavi MurthyOracleMurata MakotoXeroxChris OldsWall DataFrank OlkenLawrence Berkeley National LaboratoryDavid OrchardBEA Systems, Inc.Paul PedersenMark Logic CorporationShriram RevankarXeroxMark ReinholdSun MicrosystemsJonathan RobieSoftware AGCliff SchmidtMicrosoftJohn C. SchneiderMITREEric SedlarOracle Corp.Lew ShannonNCRAnli ShundiTIBCO ExtensibilityWilliam SheaMerrill LynchJerry L. SmithDefense Information Systems Agency (DISA)John StantonDefense Information Systems Agency (DISA)Tony StewartRivcomBob StreichCalico CommerceWilliam K. StumboXeroxHoylen SueDistributed Systems Technology Centre (DSTC Pty Ltd)Ralph SwickW3CJohn TebbuttNISTRoss ThompsonContivoMatt TimmermansMicrostarJim TrezzoOracle Corp.Steph TryphonasMicrostarMark TuckerHealth Level SevenAsir S. VedamuthuwebMethods, IncScott VorthmannTIBCO ExtensibilityPriscilla WalmsleyXMLSolutionsNorm WalshSun MicrosystemsCherry WashingtonDefense Information Systems Agency (DISA)Aki YoshidaSAP AGKongyi ZhouOracle