XML
Standards News;
April Brings New Working Drafts!
In April a significant number of working drafts
were posted by W3C. April working drafts included:
News from the Voice Browser WG
The W3C Voice Browser working group posted a working draft for reusable dialog
requirements for the Voice Markup Language. The goal of this working group
is to develop specifications to
enable access to the Web using spoken interaction. This document is part
of a set of requirements studies for voice browsers, and provides details
of the requirements for reusable components for spoken dialogs.
Reusable dialog components provide
"out-of-the-box" functionality that will enable developers to quickly build
applications by providing standard default settings and behavior. These
components shield developers from having to worry about many of the intricacies
associated with building a robust speech dialogue. However, this behavior
can be customized by a developer if necessary to provide
application-specific prompts, vocabulary, retry settings, etc.
Last-call
Public Working Draft Specification for XML Schema 1.0
The
Working Drafts for XML Schema 1.0, (published in three parts on April 7, 2000)
has been specified as a "last-call Public working draft. The three last-call
public working drafts for XML Schema 1.0 include:
The
XML Schema Language is itself represented in XML 1.0. The three parts
provide a superset of the capabilities found in XML 1.0 document type
definitions (DTDs). For example, Schemas provide for the
specification document information, such as default values for attributes and
elements that DTDs do not provide. Schemas also provide for robust,
extensible datatyping facilities that will enable validating XML processors to
supply the rigorous type checking required by XML application developers.
XML
Schema Part 0: Primer
One of the most
significant postings of April is the Primer that explains the XML Schema
Definition Language. This primer (Part 0) is a must for newcomers to
understand Part 1 and Part 2 of the specification. The "primer is a
non-normative document intended to provide an easily readable description of the
XML Schema facilities and is oriented towards quickly understanding how to
create schemas using the XML Schema language." Also of note is the
statement that the Working Group
"does not anticipate further substantial changes to the syntax described
here. . ." The
XML Schema Primer intended audience "includes application developers whose
programs read and write schema documents, and schema authors who need to know
about the features of the language, especially features that provide
functionality above and beyond what is provided by DTDs."
The
Schema Primer is divided into 5 sections. The first section is an
introduction. Section 2 concentrates on the basic mechanisms of an XML
schema. In particular, Section 2 describes how to declare the elements and
attributes that appear in XML documents. It explains features of the new
schema language that provide functionality above and beyond what is provided by
DTDs. Sections 3 and 4 provide discussions of advanced features of the new
schema language. Section 3 focuses on the namespace mechanism.
Section 4 explains how to derive types from existing types, control these
derivations, and describes mechanisms for merging together fragments of a
schema from multiple sources. Section 5 explains how to specify uniqueness
among attributes and elements, the mechanism for using types across namespaces,
and the mechanism for extending types based on namespaces. Section 5 also
describes how documents can be checked for conformance to an XML schema.
If
you come from an SGML background, the contents of this Primer are critical to
your understanding of XML schemas. We might expect that an XML schema is
much like a DTD. While there are similarities, there are many striking
differences. DTD folk need to set DTD concepts aside and be open to the
concepts and functionality within XML schemas that are different from what is
provided in a DTD. For example,
in XML Schema, there is a basic difference between complex types and
simple types. Complex types allow elements in their content and may carry
attributes, while simple types cannot have element content and cannot carry
attributes. DTDs have no such concepts. The primer explains these and many
other new concepts. Whenever possible, the Primer uses a purchase order
document to
provide a concrete example for schema definition. The purchase order
schema used in the Primer consists of a schema element and a variety of
subelements. The purchase order schema contains examples of element,
complexType, and simpleType definitions that determine the appearance of
elements and their content in instance documents.
Progress
on Cascading Style Sheets in April
April brought us two new working drafts for Cascading
Style Sheets. CSS is a style language for HTML and XML documents for
many media types including screen, paper, and voice. One draft
focuses on selectors. A W3C selector represents a structure. This
structure can be understood for instance as a condition (e.g. in a CSS rule)
that determines which elements in the document tree are matched by this
selector, or as a flat description of the HTML or XML fragment corresponding to
that structure. The proposed CSS level 3 selectors includes the selectors
of CSS level 2 and proposes new selectors for CSS3 as well as for other
languages that may need them. This document is a draft of one of the
modules for the upcoming CSS3 specification.
In
addition, a second working draft, CSS3
Introduction, has been posted. This document
explains modularization of the CSS3 specification and its test suite.
According to the abstract, "the
members of the CSS FP Working Group have decided to modularize the CSS
specification. This modularization will help to clarify the relationships
between the different parts of the specification, and reduce the size of the
complete document. It will also allow to build specific tests on a per module
basis and will help implementors in deciding which portions of CSS to
support." According to this draft "the modular nature of the
specification will make it possible for individual modules to be updated as
needed, thus allowing for a more flexible and timely evolution of the
specification as a whole."
Return
to TOC
