Addison wesley the XML schema complete reference sep 2002 ISBN 0672323745

An Example of a Complex Type Specifying Nested Element Types Section 11.4.. An Example of a Complex Type Mapping to a Database Schema Section 24.3.. An Example of a Complex Type Mapp

Mike Wooding, Chris Dix, Chris Galtenberg

Publisher : Addison WesleyPub Date : September 27, 2002ISBN : 0-672-32374-5

Pages : 1008With the successful implementation of XML Schema, developers are learning how to increase productivity, improve software reliability, minimize development time, and decrease time to market This in-depth reference is an all-in-one resource designed to help developers leverage the power and potential of XML schemas by offering a complete roadmap to their creation, design, and use.

This authoritative reference and tutorial is filled with practical insights and detailed examples The book begins by providing a conceptual introduction to XML Schema From there, coverage shifts to the W3C Schema

Recommendation and how to apply schemas to specific business goals The authors provide insight and instruction throughout on integrating XML schemas into existing technologies such as NET, Java, Visual Basic, Oracle, and more The book concludes with a complete case study designed to reinforce and illustrate material covered.

Section 7.4 The schema Element

Section 7.5 The annotation Element

Section 7.6 The appinfo Element

Section 7.7 The documentation Element

Section 7.8 The include Element

Section 7.9 The import Element

Section 7.10 The notation Element

Section 7.11 The redefine Element

Chapter 8 Element Types

Section 8.1 An Example of a Trivial Element Type

Section 8.2 Concepts and Observations

Section 8.3 The element Element

Section 8.4 The any Element

Section 9.6 The attributeGroup Element

Section 9.7 The anyAttribute Element

Section 10.5 The simpleType Element

Section 10.6 The restriction Element

Section 10.7 The list Element

Section 10.8 The union Element

Chapter 11 Complex Types

Section 11.1 An Example of a Complex Type Specifying Empty Content Section 11.2 An Example of a Complex Type That Adds Attributes to a

Simple Type

Section 11.3 An Example of a Complex Type Specifying Nested Element

Types

Section 11.4 An Example of a Complex Type Specifying Mixed Content Section 11.5 Concepts and Observations

Section 11.6 The complexType Element

Section 11.7 The simpleContent Element

Section 11.8 The complexContent Element

Section 11.9 The extension Element

Section 11.10 The restriction Element

Section 11.11 The all Element

Section 11.12 The choice Element

Section 11.13 The sequence Element

Section 11.14 The group Element

Section 13.3 The unique Element

Section 13.4 The key Element

Section 13.5 The keyref Element

Section 13.6 The selector Element

Section 13.7 The field Element

Chapter 16 PSVI Detail

Section 16.1 Schema Validation and Schema Processing

Section 16.2 The PSVI

Section 23.4 The list Element

Section 23.5 The union Element

Chapter 24 Data-oriented Schemas: Complex Types

Section 24.1 XML Schema Design Considerations

Section 24.2 An Example of a Complex Type Mapping to a Database Schema Section 24.3 An Example of a Complex Type Mapping Supporting Mixed

Content to a Database Schema

Section 24.4 Concepts and Observations

Section 24.5 complexType Element

Section 24.6 all Element

Section 24.7 annotation Element

Section 24.8 any Element

Section 24.9 anyAttribute Element

Section 24.10 attributeGroup Element

Section 24.11 choice Element

Section 24.12 complexContent Element

Section 24.13 group Element

Section 24.14 sequence Element

Section 24.15 simpleContent Element

Section 24.16 restriction Element

Section 24.17 extension Element

Many of the designations used by manufacturers and sellers to distinguish theirproducts are claimed as trademarks Where those designations appear in thisbook, and Addison-Wesley was aware of a trademark claim, the designationshave been printed with initial capital letters or in all capitals

The authors and publisher have taken care in the preparation of this book, butmake no expressed or implied warranty of any kind and assume no responsibilityfor errors or omissions No liability is assumed for incidental or consequentialdamages in connection with or arising out of the use of the information or

programs contained herein

The publisher offers discounts on this book when ordered in quantity for bulkpurchases and special sales For more information, please contact:

in Canada

For information on obtaining permission for use of material from this work,please submit a written request to:

Finally, to my wife Barbara who never ceases to amaze me Thanks for your patience, the time to write this book, and your understanding.

Mike Wooding

I would like to thank my beautiful wife Linda for all of her support on this and every project Without her support, I could not disappear for the many long hours that are required to write.

Chris Dix

To Micah

Christopher Galtenberg

To Lavinia, my lifeblood

The authoring and editorial teams for this book have worked hard to bring youthe cleanest, clearest, and most complete XML schema reference source on themarket Endless sweat, research hours, code testing, tech and definition reviewsand counter explanations, e-mail queries, dialogue, and debates passed beforethis book came to fruition Earnest efforts, stress-filled moments, and writingdeadlines have finally gotten us to press time Here is what this book means tous

The History

There are always new and hot technologies to write about (C++, Java, SQL,.NET, XML Schema, and much more) There are qualified writers eager to write

a clear and concise best-seller for your bookshelf There are millions of softwaredevelopers eager to learn There are more than a few publishers to choose from.Ultimately there are several technical books on the market within months of anynew product, platform, service, tool, or language's release that seek to describe,explain, clarify, and elaborate on a given technology's importance, utility, and

implementation However, there are very few really good books on the "why and

when" that will actually teach developers emerging technologies In fact, thehardest types of books to write discuss emerging technologies, because therereally are not many good examples Furthermore, even the "experts" frequentlydisagree on what is "right."

We spent many months—full time—writing this book We collectively havesomething like 80 years of experience Some of us are on the W3C SchemaWorking Group We believe that this combined experience, as well as the

determination writing this book, results in one of the few "really good books"previously mentioned It takes the right combination of technology, authors,publishers, and readers to pull off a book

The Book

pertain to XML Schema Despite this influx, we strongly believe that this bookprovides details that few, if any, other books provide Specifically, the

overarching goal driving this book is to provide detailed examples of every XMLSchema component In order to detail each component, this book contains anexample of the corresponding Schema document element, and all of the

associated attributes Many of the books on the market today provide surfacedetails about Schema components However, this book provides detailed

scenarios Not only are there many pages and examples of each Schema element,

there is at least one example of every single attribute of every single XML

schema document element Having accomplished that colossal task, we added

example after example integrating with many languages and technologies onmany platforms After all, what good is an XML schema by itself?

Audience

The primary goal of this book is to provide detailed information about XMLSchema The book opens with a discussion on the background and supportingRecommendations for XML Schema The book addresses how to create XMLschema documents Additionally, some of the chapters in this book cover

integrating XML schemas into other existing technologies such as Java, VisualBasic, and Oracle The audience of this book is software developers who need tocreate an XML schema or perhaps integrate one into an application This book

does not sufficiently cover aspects of the Schema Recommendation that pertain

to writing an XML schema validator

Prerequisites

Most of the text in this book requires familiarity with XML For discussions thatapply to various technologies, such as Oracle, the text requires familiarity withthe pertinent technology On the other hand, the book explains the standards thatprovide a foundation for XML Schema and even XML, such as the XML Infoset,XML Namespace, and XPath Object-oriented principles apply to XML Schema;the book requires that you have a general understanding of objects and

inheritance

The purpose of this book is to detail how to create an XML schema

Furthermore, various sections of this book discuss how and why you would usesuch a schema This book is divided into seven parts:

possibly a different schema selected using information not in the document

Note

The term XML instance as used in this book is not generic: XML is not a class of

connotation of a candidate for validation in the context where the term is used

Part II covers the W3C XML Schema Recommendation, XML Schema, in detail.

In particular, Part II details every XML schema element type and all of the

corresponding attributes Examples throughout this part of the book demonstratenearly every feature of XML Schema Part II serves as a tutorial or a referencemanual

Part III encompasses validation of XML schemas Some of the chapters in PartIII are background information, such as an in-depth discussion of post schema-validation infoset (PSVI) Other chapters are more concrete, containing codeexamples that demonstrate how to validate XML against an XML schema

Part IV covers how to apply an XML schema to achieve a particular businessgoal In particular, this part of the book addresses the target of an XML instance,such as a document or an application In other words, Part IV discusses how tocreate an XML schema such that the schema and corresponding XML instancesare helpful in providing the desired solution

The Web site is much more extensive than just a collection of files, however Inaddition to the traditionally available downloads,

http://www.XMLSchemaReference.com has lots simple online examples ofevery schema document element There are tables for each element that indicatewhat attributes are possible, as well as a brief description Although this Web site

is not a tutorial, it is a fantastic quick reference for those who already understandXML Schema in general, but might forget the specific syntax It is our hope thatthe Web site, like the book, becomes real reference material for lots of

developers

The Value

Our goal is to make it easy to create an XML schema—whether you need a

tutorial to write your first schema document, or you just need a reference book towrite your 5,000th Having created a schema, this book also gives you the samelevels of assistance to incorporate an XML schema into your application Thisbook provides as much support as you need, without ever getting in the way.Have fun working with XML schemas—we do!

Cliff Binstock: Many thanks to my wife, Amy, for putting up with months of

work on this book: days, nights, and weekends Many thanks to coauthor DavePeterson Dave's unflagging e-mails and editing, as well as his participation inthe W3C XML Schema Working Group, made this book as accurate as humanlypossible Thanks to Shelley Kronzek, executive editor, for providing the

opportunity to share some of my knowledge with you Thanks to Anne MarieWalker, the development editor, for teaching me how to write a book (which, bythe way, is very different from all the technical documents I have written overthe years) Mostly, thanks to you, the reader, for making this long journey

worthwhile I really hope that this book makes your current and future projectsmuch easier

Dave Peterson: I want to thank my wife, Greta, for putting up with me living in

another world for too many months while this book has been gestating Cliff, it'sbeen fun And thanks to Tyrrell Albaugh for repeatedly saving our sanity

towards the end

Mitchell Smith: I would like to thank my friend Cliff for getting me involved,

Shelley and Anne Marie for all of their work on this book, and Dave Buehmannand David Schrader for teaching me the expressiveness of SQL and the

capabilities of Oracle

Mike Wooding: My efforts on this book were possible because I had the

fantastic support of my wonderful wife Linda and my two daughters, Andrea andJessica Thanks for allowing me to disappear into my "cave" to complete this

Chris Dix: I would like to thank my wife Jennifer and my sons Alexander and

Wesley for this opportunity

Calvin; you are my favorites Thanks to Cliff, Shelley, and the folks at Addison-Chris Galtenberg: All my love to my Lady Lavinia and many thanks to

"The Year 2001," the most brutal and evolutionary period of my life

Cliff Binstock has more than twenty years of software development experience.

His current roles range from hands-on architecture and code development tomentoring and managing large groups of developers Cliff's object-orientedexperience began with relatively unknown languages in the 1980s and

culminated in years of development in the extremely popular C++ and Javalanguages Cliff has also spent many years working with multiple SQL

databases In 2000 and 2001, Cliff helped deliver shrink-wrap software for abiotech firm The software used multiple XML schemas to provide the softwarecontracts for various modules XML, along with appropriate supporting XMLschemas, provided a programmatic pipeline The pipeline architecture not onlysupplanted many lines of Java, but it turned many "code changes" into trivialXML edits The expertise acquired during this development effort led to thewriting of this book Cliff is the owner of the consulting firm Robust Software

Dave Peterson is principal consultant with his own firm, SGMLWorks!,

providing SGML and XML solutions for publishing and database systems

worldwide Dave has been working with SGML since before the ISO Standardwas published in 1986, and with XML since it was just a gleam in a few people'seyes He's been programming and architecting systems professionally since

1967 He helped design the system that produces and processes the largest

SGML document in the world—more than three billion characters, markup, andtext in one document (not counting graphics) He ran the document analysis thatultimately defined the document structure used by the New Zealand Parliament

technical documents Dave's first job with SGML in 1986 involved using SGML(XML was not around yet) to transfer data from one database to another He hasdesigned and programmed numerous SGML and XML processing systems Daveserved on the ISO committee that oversaw the continuing development from

1990 through 1998 Since then, he has served on the W3C Schema WorkingGroup, which produced the XML Schema Recommendation in 2001 and is nowworking on the 1.1 version He has given numerous presentations and tutorials atSGML and XML conferences, and has written about forty articles on various

SGML and XML topics He was on the editorial board of the journal Markup

Languages: Theory and Practice.

Mitchell Smith is Chief Software Architect at Array BioPharma Inc., in

Boulder, Colorado He has seventeen years of experience developing softwaresolutions and has been working with relational databases for more than twelveyears He is currently developing rapid software solutions to integrate chemists'processes, integrating hardware/software products with the existing chemo-infomatics infrastructure, and assisting chemists (in a small way) to producebreakthrough drug candidates Prior to joining Array BioPharma Inc., Mitchworked for Rational Software Corporation, where he co-architected a next-

authored several courses for Learning Tree International, including EnterpriseActive Server Pages and Microsoft Transaction Server He was involved with theActiveServerPages.com site and speaks regularly at industry conferences As apartner at Kiefer Consulting, Mike focuses on delivering advanced architecturesusing Internet standards and leveraging Microsoft's NET Framework usingmany tools, including COM+, NET, Visual Studio NET, and NET Web

Services Prior to joining Kiefer Consulting, Mike developed products with Intel,Baxter Healthcare, and several smaller Silicon Valley start-up companies Mikeholds two patents for work in robotics and DNA probe analysis In his sparetime, Mike enjoys snow skiing, wind surfing, basketball, and automating hishouse with a combination of custom and off-the-shelf hardware

Chris Dix has been developing software for fun since he was ten years old, and

doing it for a living for the past eight years Chris recently made the transitionfrom C++ and COM to C# and NET and is finding he likes it better than heexpected He's written magazine articles on SOAP and Windows development,and he has contributed to two books on XML and Web Services Chris is leaddeveloper for Navtrak, where he designs and develops products for mobile dataaccess and asset tracking

the realms of extending human intelligence through philosophy and software.Galtenberg poetry, which explores this philosophy, can be found at

http://www.deiforming.com

Part I provides detail on the foundation of the W3C XML Schema

Recommendation This foundation includes, among other topics, the W3Crecommendations that support the W3C XML Schema Recommendation

Chapter 1 provides an overview of the various W3C recommendationsthat are the foundation for the XML Schema Recommendation Theterminology and concepts from the various recommendations coalesceinto a discrete set of terms, which provide a handle with which to readthe remainder of this book

Chapter 2 provides a high-level overview of how an XML parservalidates XML This overview also covers the parser extensions

required to validate XML against an XML schema

Chapter 3 is an overview of namespaces This overview includes adiscussion of the W3C XML Namespace Recommendation

Namespaces are one of the first considerations when creating an XMLschema document

Chapter 4 covers a basic description of the respective grammars

XPath locates elements and attributes for Identity Constraints

XPointer locates elements for inclusion in an XML schema document

Chapter 5 covers the abstract representation of both XML documentsand XML schemas This chapter also introduces XML infosets, whichare the abstract versions of documents on which an XML schemaprocessor operates

CONTENTS

1.1 Why XML?

For as long as there have been programming languages, programmers have beentrying to simplify ways to transmit data from one section of code to another Thesimplification comes mostly in the form of standards Standardization has

evolved from solely technical specifications to standards accepted by a largecommunity The latter often involves programmatic enforcement

Communicating between sections of code has evolved over the years At a

macroscopic level, the following progression roughly describes the evolution ofsoftware development:

program The availability of these parsers has promoted the use of XML as the

XML is also typically considered "human-readable." That is, a developer (orfrequently even a business analyst) can examine an XML stream and know thatthe stream is correct or, conversely, identify errors Like any other

constraints The ability to guide the layout of an XML document makes thatXML document much more predictable A programmer can examine an XMLschema and know exactly what corresponding XML documents look like

Additionally, a program can reject an XML document out of hand when the

XML does not conform to the appropriate XML schema

An XML schema specifies valid elements and attributes in an XML instance.Furthermore, a schema specifies the exact element hierarchy (for nested

representations of schema components; the other elements support assembling aschema from a set of schema documents

1.2.2 Benefits of an XML Schema

XML schemas provide innumerable benefits to a development environment.Many of these benefits are intangible or economic in nature, indirectly

increasing productivity and decreasing time-to-market

The most important tangible aspect of an XML schema is that an XML schemaspecifies a contract between software applications or between parts of a softwareapplication A developer creating software to generate XML, or an unfortunateemployee who has to manually create XML, knows the target A developerwriting software that receives the XML not only knows what to expect, but canvalidate the incoming XML against the schema As a specification of an

interface, an XML schema might not be as easy to read as an English document,but it is incredibly precise Furthermore, the writer can clarify the intent of aschema with XML comments and XML schema annotations—each with

embedded English (or any other language)

For software development shops creating large applications, the notion of acontract simplifies modularization, resource allocation, testing, and deployment.Modularizing the code is easier because the boundaries are readily identifiable(each boundary is an XML document) This in turn makes resource allocationeasier: Individual developers receive specific tasks, each of which has well-defined inputs and outputs Testing is also much easier: The developer

generating XML ensures that the generated XML validates against the XMLschema, and the developer receiving the XML can easily create test XML

documents in a common editor Subsequently, integration testing is usually farmore successful than with traditional data (such as passing objects and

structures) Finally, even deployment is simpler: Versions of code that generatethe XML can be deployed at different times than code that receives the XML—assuming that the schema is stable

Modern distributed environments compound the issues just mentioned for a

generate XML that is sent to the Web service In the case of a Web service, theXML schema is the crucial piece of documentation Likewise, the XML schema

is the contract by which everyone abides For example, the developer can changethe underlying Web service as long as the XML schema does not change

XML schemas are incredibly precise; they are also verbose This should come as

no surprise to anyone who interacts frequently with the equally wordy plainXML, the foundation for XML schemas

There is a noticeable amount of overhead to using XML The XML verbosenessjust mentioned translates directly into extra overhead for deciphering XML.Understanding XML requires a full parser A native programming structure (such

as a C struct or a Java class) is much more efficient XML validatesagainst an XML schema This validation is time-consuming Worse, loading anXML schema document also requires parsing XML As computers get faster andfaster, developers tend to ignore the effort required from a processor Of course,

in some cases, the programmer can cache schema information for speed Even

so, a user might perceive the time delay caused by a single validation Almostcertainly, the amount of time required for multiple validations has the potential

to annoy users

1.3 The World Wide Web Consortium (W3C)

Recommendations

A number of W3C Recommendations (the W3C chooses to call them

processing instructions instead (One use of processing instructions in SGML is

developers are "users.")

The XML Recommendation does not attempt to define the "abstract" document.The XML Recommendation defines the XML and Document Type Definition(DTD) grammars Further-more, the Recommendation discusses well-formedXML documents (documents that conform to the XML grammar) and validXML documents (documents that conform to a DTD)

1.3.2 The Namespace Recommendation

The W3C released the Namespace Recommendation in January 1999

Namespaces are important during document validation Different sources

provide parts of a DTD (in the same way that one XML schema referencesanother) Namespaces provide a mechanism for avoiding naming conflicts.For example, a DTD might define a list element type designed for ordinarywritten documents such as a book or magazine article At some point, someonemight want to add the MathML package for standardized mathematical formulamarkup Unfortunately, MathML has a distinct list element type, with quitedifferent content There might well be a large body of existing documents,

making a change to the document list element type difficult Similarly,

changing the MathML element complicates the use of standardized tools tohandle math

The solution is to have one namespace for the document DTD's element typesand another for the MathML element types A namespace-aware processor reads

a revision of the original DTD that implies the first namespace, and the new

MathML element types imply the MathML namespace The XML DTD-basedvalidator selects the correct list element type to validate against based oncontext All XML schema-based processors are namespace-aware, and operatethis way

1.3.3 The Infoset Recommendation

promulgated in October 2001 Infoset is a commonly used abbreviation for

Information Set The purpose of the Infoset Recommendation is to standardize

terminology by describing an object-oriented data structure that captures theabstract tree structure of elements in an XML document In an XML document(a string of characters), the structure is a nested partition delimited by tags

Many of the elements described by these tags contain data between start-tags andend-tags In an XML infoset, an object-oriented structure mirrors the tags in anXML document, with data characters being the leaves of the abstract tree

structure

1.3.4 The XPath Recommendation

The XPath Recommendation is one of the earlier XML-related

Recommendations, released in November 1999 An XPath is a mechanism fornavigating through an XML document hierarchy The XPath notation is

intentionally similar to widely accepted URI path notation—XPaths are not

XML An XPath can provide the location of a schema, sets of schema

components, or individual schema components Additionally, a subset of theXPath notation provides a language for specifying elements for identity

document (The Schema and Infoset Working Groups had members in commonand tracked one another's work reasonably carefully.)

Because of the dependence on an XML infoset, a schema processor cannot

handle parseable entities: The XML parser must first identify, read, and parsethese entities while creating the infoset The XML parser expands the entitiesbefore schema processing begins Therefore, a document with a nontrivial entitystructure must have a DTD that declares those entities, although there is

XML Schema Part 2: Datatypes, http://www.w3.org/TR/xmlschema-2: Acomplete reference for the numerous built-in datatypes

At this book's publication time, the date on each of these Recommendations isMay 2, 2001 http://www.w3.org/XML/Schema references many other relateddocuments that might be of interest

Working just from the Recommendations, you need to read all the

Recommendations to be able to create an XML schema Although Part 0 is afantastic tutorial, the examples are not comprehensive Part I covers everythingyou need to implement an XML validator; some of that is overkill if you justwant to write a schema The intent of this book is to provide one document thatcovers all three parts at an appropriate level of detail This book is for the

The poignant distinction between intensional and extensional objects is that in anintensional language, an instance exists because of instantiation For example,you might use 'instance = new(class)' or some other similar

syntax Extensionally, however, an object simply is or is not an instance of aparticular class according to whether or not it satisfies the class's "restrictors."Consider, for example, the XML element '<taggy />' It claims to be an

instance of a taggy element type Presumably, but not necessarily, the schema

contains that element type (described by '<element name="taggy"

/>') Furthermore, the XML element must satisfy the structure and attributeconstraints specified by that element type in order to qualify as an instance See

Section 1.5.4 for a discussion of element types

With extensional programming, validation software accepts or rejects potentialinstances With intensional programming, an instance is implicitly valid: Thesoftware prohibits creation of an instance that does not satisfy the restrictions ofits class

In an object-oriented language such as C++ or Java, there is one inheritancemechanism The derived class has full control of the functionality New

functionality comes from creating new methods or overriding existing ones In

an XML schema, an extension is analogous to creating a method or adding new properties A restriction compares to overriding an existing method or restricting existing properties The XML schema language—not extensional programming

in general—prohibits certain derivations that are common in existing intensional

languages For example, schemas do not permit element types in an extension tooverride (subclass) the corresponding structure type

consistent terminology Ultimately, despite the strong desire to reuse commonterminology, the book presents some new terms in the following four

circumstances:

When an existing term has multiple connotations For example, abstract might mean an abstract schema as opposed to a concrete XML schema document The term abstract might also mean a non-instantiable class

(versus a "concrete" instantiable class)

When many similar words are used, perhaps with slight nuances, in whichone word would suffice For example, this book consistently presents the

term specify instead of define or declare.

When different Recommendations use different words for essentially thesame concepts, we will select one term for the concept and use it

consistently (except when explaining the alternate terminology you mightfind in a particular Recommendation)

establishes the concept of various types In most of the discussion in this book,

the form of each type is irrelevant

Simple type: A component of a schema; a class whose instances are elements

and attributes; it restricts the value of its instances according to rules set forth inthe Schema Recommendation

Complex type: A component of a schema; a class whose instances are elements;

it restricts the content and attribute set of its instances according to rules set forth

in the Schema Recommendation

complex type which is the value of the type property of an element type; the simple type that is the value of the type property of an attribute type.

abstract attribute—although this is a common use of the word 'abstract'

Non-instantiable class:

1 (General) A class that can only have instances by virtue of them being instances of another class derived from this class.

A complex type or element type that requires a derivation or substitution toinstantiate directly in an XML instance

XML instance: An XML document—or even part of a document—whose

validity is being determined Specifically, the validity of this document depends

on examining an XML schema specified by the XML instance, or possibly adifferent schema selected using information not in the document The term 'XMLinstance' as used in this book is not generic: XML is not a class of which thesecharacter strings are instances An XML document (or a fragment of one) iscalled an "XML instance" only when it is intended to carry the connotation of acandidate for validation in the context where the term is used The terms

a specific element or attribute in an XML instance, respectively

XML validator: An XML validator is a program—or a module in a program—

that examines XML purporting to be an XML instance and validates that XMLagainst an XML schema

Base type: Simple types and complex types benefit from object-oriented class

inheritance A base type is the simple type or complex type of which there is a derivation A base type is analogous to what some might call a superclass or

1.5.2 Schema Values

Many of the chapters in this book discuss how to express the XML

representation of a particular schema component Each of these elements—theXML representation of a component—has multiple, often optional attributes Inmany cases, the values of these attributes refer to another schema component,perhaps a built-in datatype The value of an attribute is always a character string.This string must always conform to a datatype, although the type may providemany—or no—constraints on the value in the string The following definitionsilluminate the subsequent datatypes that appear frequently in the discussion ofschema attribute values:

NCName: An NCName is a name that does not contain a colon character (The

etymology of 'NCName' is from "no-colon name" or "non-colonized name";however, neither of these terms is in common use.)

NCName that in the scope of an appropriate namespace declaration determines a

namespace), a colon character, and a local name (another NCName) Note that a default namespace might imply a namespace for a QName, in which case the prefix and colon is omitted and the QName is an NCName (The QName

it (which are all character strings), and the corresponding abstract objects (whichexplicitly embody the structure recognized by the parser)

Similarly, a parallel exists between the concepts of DTDs and those of schemas.Both create classes (which are DTD "element types") whose instances are

particular kinds of elements The same parallels exist for other classes having to

do with whole documents and parts of elements If you are familiar with DTDs,being aware of the parallels will make learning schemas easier

Often the distinction between the concrete and abstract versions of a concept isirrelevant: specifically, after the parser has created an abstract copy of the

concrete document Similarly, the processes of validation against DTDs andschemas are pretty much equivalent except in the details of which properties ofthe corresponding abstract structures record the results

1.5.4 Element Terminology

This section covers the difference between concrete and abstract elements Inaddition, this section introduces some terms specific to elements

1.5.4.1 (Concrete) Elements

Fortunately, the XML Recommendation and the ISO SGML Standard (ISO

8879:1986) use the word 'element' consistently An element is a string of

characters satisfying certain lexical and grammatical constraints described in theXML Recommendation An XML parser recognizes certain substrings of theelement as markup; the remaining characters are data The XML parser furtherdistinguishes characters within the markup strings as punctuation or metadata

Elements normally begin with a start-tag and finish with an end-tag There is aspecial case in which the element consists entirely of an "empty-element" tag.For the purpose of this discussion, the part of a tag of interest is the (metadata)name immediately following the opening punctuation This name has been

variously called the element's "generic identifier," "name," "element type-name,"