extensibility

Frequently Asked Questions


Schemas 

Q:   What is a schema?

A:   A schema is a framework for XML documents. It describes the structures and vocabulary that may appear within an XML document conforming to that schema. A schema language uses its own formal grammar and distinctive dialect to express document structures. If a set of documents uses the same schema, the documents may have different content, but they can share common processing.

 

Q:   What is the difference between a schema and an XML document? 

A:   An XML schema defines an XML document's structure and content. Schemas describe the mark-up or meta-data contained in the XML document as well as the type of data contained by the mark-up. Schemas do not specify or supply the data itself.  The W3C (World Wide Web Consortium) is currently developing the XSDL (XML Schema Definition Language) proposal that uses XML syntax to describe XML document structures. Most XML schema dialects ö but not DTDs (Document Type Definitions) ö use XML syntax and their schemas are also XML documents themselves.

 

Q:   What is the difference between an XML schema and a DTD (Document Type Definition)? 

A:  The DTD format is specified by the W3C XML 1.0 specification. XML Authorityú uses the term 'schema' to describe both   DTDs and various other schema proposals, including:

á       DCD (Document Content Description),

á       DDML (Document Definition Markup Language),

á       SOX (Schema for Object-oriented XML),

á       XDR (IE5 compliant subset of XML-Data), and

á       XSDL (XML Schema Definition Language)

XML Authority provides a consistent interface you can use when working with any of these formats.   Schemas are frequently contrasted to DTDs, although they serve the same function. Typically, XML schemas are portrayed as the 'next generation'  going beyond DTDs, but DTDs are really the 'first generation' of schemas. DTDs have much  software support in XML 1.0-compliant parsers and applications, but they are written in EBNF (Extended Backus Naur Form), not XML. EBNF is a complex language with roots in SGML (Standard Generalized Markup Language).  This means that DTDs cannot be treated as XML documents by applications designed to process XML.

 

Q:   Why are schemas important?

A:   Schemas define constraints that documents must meet to be 'valid' for safe processing. Schemas provide an extra level of safety above the core XML document structure, making it much simpler to exchange information reliably.

Another key task schemas help manage is the integration of documents and data. XML provides a medium in which both document and data structures can co-exist. Data may dominate a document (as when a document represents a relational database table) or appear as fragments scattered among document structures. When data and documents from multiple sources must merge into a single document, schemas can smooth the process by verifying that the inputs are what they claim to be and that the output is delivered as it should be.

Schemas also help programs separate the parts of a document they need from the parts they can ignore, helping search engines, data mining tools, and agents. XML documents can use schemas to identify themselves, advertising that they contain information of a particular type, and programs can use that identity and the structural information it contains to inspect documents and extract (or create) the right information.

Whether an organization is using XML to facilitate electronic commerce, manage its documents, present a Web site for public consumption, or exchange information among internal processes, schemas provide a framework that ensures the safe transmission of information using common vocabularies and protocols.

 

Q:   Which type of schema should I create?

A:   It depends on your application's requirements. If the application is data-intensive, XML schemas provide strong data typing (unlike DTDs) and allow you to describe your own data, while still using a standard language and set of tools.

      If your application is document-centric (for example, will be used for content management, document interchange, or large documentation projects to provide authors guidance), either a DTD or an XML schema will suffice. Schemas may be structured in different ways, representing very different requirements. In the end, experimentation may yield the best results.

Certain XML schema dialects (e.g. XDR) provide built-in mechanisms for extensibility. They are built on an open content model, so schema authors are free to add their own elements and attributes to the schema.

The DTD extension mechanism is limited to string substitution (parameter entities) and does not make relationships explicit. Two elements defined to have the same content models are not explicitly the same thing. Likewise, a group of attributes defined as a parameter entity and reused are not logically a group, they are just coincidentally a group.

Often it is best to begin by modifying an existing DTD or XML schema. Though you may not find a schema to meet a particular need, many schemas can be customized for a specific implementation. Corporate libraries and vocabularies can be built quickly by using appropriate industry and application schemas. XML Authority will import these schemas and give you a jumpstart.

 

Q:   Which schema dialect should I use? 

A:   A schema dialect like XDR (IE5 compliant subset of XML-Data) or SOX (Schema for Object-oriented XML) lets you take advantage of features like data-typing and namespaces immediately.  These languages are stable and have support in the form of validating parsers.   If necessary, conversions from these schema formats to the emerging schema standard of the W3C can be enabled through the use of XML Authority.

Another approach is to develop DTDs with an eye toward future conversion to XML schemas. XML Authority can convert among XML schema dialects and will support the final W3C XML Schema Definition Language Recommendation.

 

Q:   How do I integrate schemas into my applications (e.g., databases)? 

A:   Extensibility's Schema Adjunct Framework SDK is one possible Java-based solution if you need to specify how XML   structures are mapped into object-based or relational systems, provide business logic associated with structures, state how structures should be formatted, or state additional constraints not expressible in a schema language.

A schema adjunct provides the information that enables the use of a schema (and its instances) within a particular application.  This means that a given schema can be enabled in a family of inter-operating applications by an equal number of adjuncts.  Conversely, a given application can be applied to a variety of schemas by supplying an adjunct for each schema.

XML-processing applications can use a schema adjunct for metadata that is beyond the scope of a schema, rather than embedding the metadata in the application where it could be difficult to maintain.  The Schema Adjunct Framework (SAF) API defines Java interfaces to extract that metadata as needed.

 

Q:   What support is there for using schemas (e.g., validating parsers)? 

A:   Several commercial, shareware, and open-source XML parsers and processors are available.  XMLSOFTWARE has links for downloading them.  The Apache XML Project has DTD parsers for Java, C++, and Perl.  Commerce One includes a SOX parser in its XML Development Kit (XDK).

A parser or processor takes an XML document and makes its structure and content available to an application, usually via a standard interface like SAX (Simple API for XML) or the DOM (Document Object Model). If you need to validate documents on the widest range of platforms, a validating Java parser should be used.

 

Q:   Can't I create my own schema with a simple text editor?

A:   Yes, but you will probably encounter difficulties manipulating abstract constructs as text and maintaining version control as well as conforming to the syntax of the schema dialect. A graphical design tool for schema creation, conversion and management like Extensibility's XML Authority makes the entire process much easier.

 

Creating Schemas In XML Authority 

Q:   How can I change the default dialect for new schemas I create? 

A:   Select Preferences from the Edit Menu to open the Preferences window. At the top left of the window is the Default Schema Type box. This box contains a drop-down list of dialects supported by XML Authority. Choose a dialect from the list as a default and click on <OK>.

 

Q:   What is the difference between attributes and elements? 

A:   Elements and attributes are both containers for information. Many times the choice between an element and an attribute seems arbitrary, almost a matter of style. While the choice may indeed be arbitrary in some cases, the different types of content models and constraints these two containers support may tip the scale in one direction or the other.

One way to look at elements and attributes suggests that elements are the 'real' containers of data, while attributes annotate elements with additional information describing the content of the element. In the case of empty elements, attributes provide additional information about why the element is present and possibly about what content it represents.

The intrinsic differences between elements and attributes in XML 1.0 tend to define how these two containers are used. The most fundamental difference, which will likely continue to hold through future iterations of XML development, is that elements can contain child elements as well as content, while attributes can only hold content. If it seems at all likely that you'll need to break down the information stored in a container, make that container an element.

Attributes do have some advantages over elements, however. In XML 1.0, and in the W3C XML Schema Definition Language (XSDL) working draft, only attributes may have default values assigned to them by the schema. In XML 1.0, attributes also have much stronger constraints ö you can limit the acceptable values of an attribute to a class of values (notation or entity names) or provide an enumerated list of acceptable values.  XML Authority provides a larger list of possible constraints (data types) for elements and attributes than is available in XML 1.0 through the use of the DT4DTD convention.  Free open source code that allows runtime support for these data types is available at www.extensibility.com/dt4dtd.

XML Authority also lets you create your own data types using notations. Notations created in the Notations window will be available for use in both element and attribute declarations as data types.

 

After Creating Schemas

Q:  I've created my DTD or schema, now what do I do with it?

A:   There are two basic approaches to programming XML ö SAX (Simple API for XML); and the W3C DOM (Document Object Model). SAX is used with event-driven XML, and the DOM is specific to tree-based XML parsers. Your application must provide hooks to integrate the DTD or schema with the interface you've chosen (SAX or the DOM).

To read an XML document from a program, you can:

Use your schema as a test-bed for validation. As the application moves into production, the schema will illustrate the application's components and rules.

 

Q:  Can I validate the schemas themselves to see if they conform to the syntactical structure of the schema dialect in they are written?

A:   Yes, any schema can be imported into XML Authority to find out if it is valid.  Or you can go to Extensibility's XMLSchema.com site and click on Validate in the menu bar.  Extensibility is also introducing SchemaStreamú a powerful service where developers can create an interface that, via the Internet, will allow for the validation and/or conversion processing of schemas. The service is being offered for free, however it does require custom application development by the end user.

 

Miscellaneous

Q:   Will XML Authority support the W3C XML Schema Definition Language (XSDL) specification when ready?

A:   Yes. XML Authority will conform to the W3C XSDL Recommendation (a Candidate Recommendation is expected April 2000).

 

 

Copyright 2000 Extensibility, Inc.

Suite 250, 200 Franklin Street, Chapel Hill, North Carolina 27516