We envision applications of XML in which a documentinstance may contain markup defined in multiple schemas.These schemas may have been authored independently.Onemotivation for this is that writing good schemas is hard, so itis beneficial to reuse parts from existing, well-designed schemas.Another is the advantage of allowing search engines or othertools to operate over a range of documents that vary in manyrespects but use common names for common element types.
These considerations require that document constructsshould have universal names, whose scope extends beyond theircontaining document. This specification proposes a mechanism,
XML Namespaces are based on the use of
XML syntax does not allow direct use of a URI as anamespace name,because URIs can contain characters not allowed in names.Consequently, thenamespace name serves as a proxy for a URI.A special processing instruction described below is usedto
To accomplish this, the production for No
The namespace name, unless it is "xml", must have beendeclared in axml is reserved, and considered tohave been implicitly declared.
To enable the proper use of
Element types may be given as
Attribute names are given as
I have to write a schema for manuals. As manuals havemathematical expressions, my schema has to allow them.
Fortunately, W3C has a schema called MathML. As I knowlittle about mathematical expressions, I would like to useMathML as is. I do not even want to read what is defined inMathML. If a better schema for mathematical expressionsappears later, I will switch to that schema.
Although I do not care about internal structures of mathematicalexpressions, I do want to restrict where they may appear.I do not allow them in footnotes. I only allowthem as direct subordinates of sections and subsections.
Writers will use XML editors to edit manuals. In thenear future, mathematical expression editors for MathMLwill show up in the market. My writers will use sucheditors to edit mathematical expressions in manuals.While editing manuals with XML editors, writers canintroduce mathematical expressions, provided that myschema allows mathematical expressions there. Then,mathematical expression editors are automaticallyinvoked. After creating mathematical expressions,writers close math editor windows, and resume editingin XML editors.
Observe that implementation of XML editors does notrequire implementation of mathematical expressions, andthat mathematical expression editors are dedicated toMathML. Neither editor need know the entire document orschema.
I have to write a schema for on-line novels. Because ofsome regulation, each novel has to have metadata. Theschema of such metadata is already defined by somebody (thegovernment, for example). I have to use that metadata schemaas is. No change is allowed.
As in the previous case, I do not care about the internalstructure of metadata. But I allow metadata to appear as the eldestchild of the novel element only.
Writers write novels with XML editors. The editors use myschema. But writers do not provide metadata. Writerssee no metadata.
Somebody examines each novel and then creates metadata. Ifthat novel is a pornography, he or she will specify thisinformation in the metadata. But the novel is not modifiedat all. The only change is metadata. Therefore, metadataediting tools do not provide editing of novels, but onlyprovide metadata editing.
If the schema for metadata is revised by thegovernment, I simply reference to the new schema.Writers do not rewrite novels. If the revision isbackward-compatible, existing metadata (embedded withinnovels) remains valid. If not, metadata has to beedited manually or converted automatically.
My schema for manuals should provide tables. But I donot want to study columns and rows. I would like touse somebody's schema for tables. I simply referto that schema.
Although I do not care about columns and rows, I do carepermissible about subordinates of entries. I would like toallow data characters, phrase elements, andmathematical expressions only. Nothing else can appearwithin entries.
Editing of tables is similar to that of mathematicalexpresssions, but we need recursive editing. A writeredits a manual with an XML editor. When he or sheintroduces a table, a table editor is automaticallyinvoked. The table editor is dedicated to tables, anddoes not use my schema. After creating rows, columns,and entries, the XML editor is recursively invoked tocreate subordinates of entries.
Imagine an XML document representing an invoice for books. Ifpublic schemas exist for elements and attributes describingbooks, electronic transactions and digital signatures, theinvoice author should be able to use these, rather than inventingnew element and attribute types. Any reader of the invoicedocument should be able to infer a consistent meaning to itscontents, the same meaning as if the elements and attributes hadappeared in a different kind of document (such as an invoice forautomotive parts, or an inventory of books or a digital signatureon a legal contract). Any search tool should locate the elements,regardless of the document in which they reside. Further, sinceseveral schemas may choose the same name (e.g. "size")for elements or attributes with different meanings, these must bedistinguished if used within the same document.
The namespace syntax presented in this working draft is intendedto support the namespace needs expressed by other W3C activities, toenable interoperability and to provide for future enhancements to theXML specification. Unfortunately, the syntax presented is not sufficientlyrobust to describe the blind interchange of validated documents whichcontain elements and attributes whose types are defined in severalschemas. Therefore, to provide insight into the intent of the namespacesyntax, this draft includes a brief summary of the SIG discussion andrationale. This section will not attempt to present detailed technicaldiscussion nor will it document the individual contributions of thosewho participated in the discussion. These details are available in the
The namespace discussion has resulted in no changes to the XML 1.0syntax; colons continue to be valid name characters. Our intent is toenable the development of namespace aware applications without addinglarge passages to the XML specification and without adding significantburden to XML application developers. In developing this proposal wehave avoided several features and functions we believe will be includedin the full namespace specification in a future release of the XMLspecification.
Specifically, this working draft does not establish semantics forvalidating document instances against multiple schemas, the mechanicsfor minimizing namespace names, address whether qualified attributesshould be constrained, or if there should be constraints placed onother name characters. It is anticipated this proposal will promotethe development of industry experience in regards to multiple schemavalidation, inheritance, sub-classing, editing and cut-and-pastepasteoperation, andapplication behaviors that will be reflected in future versions ofthe XML specification.
This working draft does add constraints to the XML syntax by limitingthe use of colons in names and establishing a convention fornamespace declarations. It is the intent of these constraints to limitthe namespace syntax sufficiently that future extensions can be definedto resolve remaining namespace issues. It is expected that legacy dataconforming to this note will be compatible with these solutions. Note:there is no guarantee that any namespace mechanism will be adopted forXML, nor that the mechanism will in fact be compatible with the syntaxdescribed in this working draft.
The XML specification uses PI target Root element type in doctype declaration Element type in start-, empty-element, and end-tags, andin element type declarations Attribute names, in start-tags, and in attribute listdeclarations As the value of ID, IDREF(S), and ENTITY(IES) attributes(note that the values in NMTOKEN(S) attributes are NMTOKENS, not names) Entity names, in declarations and references (general and parameterentities) Notation names, in NDATA entity declarations and Notationdeclarations (As LatinName) as the encoding name in an XML declarationName that is the first and leastcontroversial candidate for qualification is the element type.
Existing SGML practice shows that attributes are often usedfor much the same purposes as elements, with the choicedetermined by evolutionary history and design aesthetics as oftenas by differences in element and attribute capabilities.Also, certain kinds of attributes are used on a wide rangeof element types (for example, those employed in XML Links, thosethat might indicate the datatype of an element, etc.).Thus, attribute names are a strong candidate for qualification.
Furthermore, on the basis of consistency and simplicity, it might be arguedthat if one instance of Name is to be qualified, all should be.
On the other hand, attributes are already qualified by element types;that is, permissible values, defaults, and semantics of attributesdepend on element types. It has been argued that furtherqualification of attributes by namespaces is unnecessary, and is evenharmful for validation (see 4.2). Those attributes (e.g., xml:lang)which apply to all element types should rather be captured by adifferent mechanism (e.g.,#ALL in the WebSGML adaptation), as theirpermissible values, defaults, and semantics do not depend on elementtypes.
Perhaps the most complicated issue surrounding namespaces is validation.In the discussion, many viewed validation as any process that verifieddocument instance against a schema while others often referred tovalidation as "plain old DTD-wise validation with an XML processor,not any other kind of validation with an application". This whitepaper tries to support both
For generic schema validation it is anticipated that applicationswill validate against a set of semantics that are either predefinedin an application standard or expressed in machine readable syntax.The system literal in the namespace declaration should be used toidentify the specific schema and any associated data resources.
The two most commonly discussed approaches to XML validation werefragment merging and validation of a grove of independent fragments.These methods differ in how the the validation process is implemented,and should yield the same result.This specification most directly supports validation by fragmentmerging. Fragment merging validates the document instance against aDTD created by merging elements from the constituent DTD fragments.The merged-DTD may be created either by man or machine, on the flyor prior to validation. This approach has the advantage that oncethe merged-DTD is created, the validation process is unchanged fromcurrent SGML/XML practice.
XML validation using a
In considering the validation issues, it became apparent to manythat we have not arrived at an consensus about what it means, in thegeneral case, to apply an attribute from one schema to an elementfrom another schema. Coupled with a growing concern about detailedmeaning of multiple schema validation and a desire to develop an XMLbased syntax to express a superset of the SGML DTD semantics, it wasdecided to support the most straight forward XML validation techniquethat supported the requirements and which will also foster an environmentwhere application developers can evolve working models of multiplenamespace validation with various schema syntaxes.
Two mechanisms were discussed to associate between elementsand namespace schemas; qualified names and a reserved attribute. While manyin the discussion admired the simplicity of the reserved-attribute approachwhich required no namespace declaration and no new syntax, thequalified namespace prefix syntax was chosen because it supports tworequirements not possible with URI attributes. In addition, namespacequalifiers may be more compact, more meaningful to a reader, easierto understand, describe and use than a reserved attribute.
Qualified names support the requirement to identify the schema foran attribute and to be able to apply an attribute from one documentfragment to an element from another document fragment. The use of URIattributes would not allow an attribute from one namespace to be appliedto an element from a different namespace fragment. Additionally, manybelieve qualifiers are needed for other names; id, idrefs, andenumerated attribute values and perhaps should be permitted on allnames. This qualified name syntax will not need to change if we decideto support additional name types in the future.
This working draft does not specify how the URI system literal inthe Namespace Declaration PI is to be used, aside from saying thatit identifies the namespace schema.We anticipate thatvalidatingXML processors will use the QName for validation. Otherapplications are free to choose whether and how the URI,LocalPart pair areinterpreted. Note: a future version of the namespace specificationthat addresses schema validation semantics may require the interpretationof the URI, LocalPart pair to be formalized.
A validating XML processor must be able to disambiguate betweenQNames that have the same LocalParts. One intent is to support the abilityto merge two document fragments that have contain same generic identifierwhile still performing XML validation against the original content models.This ability to differentiate may also ease the deployment of stylesheetsand the development other processing applications. Finally, becauseapplications need only to control the NSPart prefix, qualified namessimplify avoiding namespace collisions.
The syntax presented in this working draft uses a reserved processinginstruction (PI) to associate a namespace qualifier with a networkresource. In the discussions many alternatives were offered, includingusing a new declaration type, system notations or XLL links. While manyconsidered PIs as the least desirable long term option, it was chosen forthis draft because it is the most compatible with existing processingsystems and should prove easy to migrate to another syntax in the future.
The ability to associate support multiple schemas with a name spacequalifier was discussed. The multiple associations could provide bothmachine and human readable schemas or even multiple machine schemas.The namespace syntax in this working draft requires that there beexactly one namespace declaration PI for each namespace name.Future namespacespecifications may establish conventions which support multipleassociations as well as a mechanism to qualify a particular attributeof a specific element in a namespace.
The namespace syntax presented in this working draft severelyconstrains qualified names. The following constraints were chosenbased on an understanding of the immediate requirements of other W3Cactives and to reserve syntactical constructs to support extensionsof the namespace mechanisms.