Members of the IETF Centralized Conferencing (XCON) Working Group have
released an updated draft for the "Conference Information Data Model
for Centralized Conferencing (XCON)" specification. The document
defines an Extensible Markup Language (XML)-based conference information
data model for centralized conferencing (XCON). A conference information
data model is designed to convey information about the conference and
about participation in the conference. The conference information data
model defined in this document constitutes an extension of the data
format specified in the Session Initiation Protocol (SIP) Event Package
for Conference State. Appendix A supplies a Non-Normative RELAX NG Schema
in XML format. Conference objects are a fundamental concept in
Centralized Conferencing, as described in the "Centralized Conferencing
Framework." A conference object contains data that represents a
conference during each of its various stages (e.g., created/creation,
reserved/reservation, active/activation, completed/completion). A
conference object contains the core information of a conference (i.e.,
capabilities, membership, call control signaling, media, etc.) and
specifies who, and in which way that information can be manipulated. A
conference object can be manipulated using a conference control protocol
at a conference server. The conference object represents a particular
instantiation of a conference information data model. The core data set
called the 'conference information data model' is defined in this
document using an Extensible Markup Language (XML)-based language. The
data model specified in this document is the result of extending the
data format defined in RFC 4575 (A Session Initiation Protocol - SIP)
with new elements. Examples of such extensions include scheduling elements,
media control elements, floor control elements, non-SIP URIs, and
addition of localization extensions to text elements. This data model
can be used by conference servers providing different types of basic
conferences. It is expected that this data model can be further extended
with new elements in the future in order to implement additional advanced
features. More Information
Saturday, November 3, 2007
Device Independent Authoring Language (DIAL) Part 0: Primer
W3C announced that the Ubiquitous Web Applications Working Group has
published a Working Draft for DIAL Part 0: Primer, updating the earlier
document of 2006-10-10. This document provides an introduction to, and
the benefits of, DIAL (the Device Independent Authoring Language). The
most recent DIAL specification Working Draft (2007-07) defines a
markup language for the filtering and presentation of Web page content
available across different delivery contexts. This will facilitate an
optimal user experience following adaptation of the DIAL instance document.
DIAL is a language profile based on existing W3C XML vocabularies and
CSS modules. These provide standard mechanisms for representing Web page
structure, presentation and form interaction. The DIAL also makes use of
the DISelect metadata vocabulary ("Content Selection for Device
Independence -- DISelect") for overcoming the authoring challenges
("Authoring Challenges for Device Independence") inherent in authoring
for multiple delivery contexts. The DIAL Primer summarizes the concept
of device independence, the scenarios in which it could be used, and
the considerations in order to achieve that goal. It then describes the
role of DIAL in ensuring the delivery of content suitable for the user,
device and inherent circumstances in which it was requested. DIAL
facilitates writing a Web page that can be presented by a range of
devices, with differing capabilities and states; and consumed by users
with differing preferences and entitlements (such varying conditions
are illustrated in 'Delivery context characteristics'). This is achieved
by allowing authors to declare authorial intent as to the conditions
under which content should be chosen or filtered. When a request is made
for a DIAL document, it must pass through at least one DIAL processor
before being presented to the requesting user. DIAL processors may exist
at any of the server, optional intermediary adaptation, or client layers.
Their role is to determine whether to select or filter out blocks of
content marked up with DISelect expressions. The evaluation of these
expressions requires the processor to query the Delivery Context so
that the decision to select or filter content involves the specific
conditions under which the request was made. After all DIAL processing
is complete, all content selections will have been resolved. Since
DIAL implements XHTML 2.0 metadata extensions, it allows other metadata
standards to be plugged in to allow content to be selected or excluded
for rendering based on variable business rules. These could include
flagging the nature of the content (such as erotic or violent), or by
indicating that it should only be shown in a certain location or time
of day. W3C's Ubiquitous Web Applications Working Group was chartered
through March 31, 2009, seeking to simplify the creation of distributed
Web applications involving a wide diversity of devices, including
desktop computers, office equipment, home media appliances, mobile
devices (phones), physical sensors and effectors (including RFID and
barcodes). Click Here
published a Working Draft for DIAL Part 0: Primer, updating the earlier
document of 2006-10-10. This document provides an introduction to, and
the benefits of, DIAL (the Device Independent Authoring Language). The
most recent DIAL specification Working Draft (2007-07) defines a
markup language for the filtering and presentation of Web page content
available across different delivery contexts. This will facilitate an
optimal user experience following adaptation of the DIAL instance document.
DIAL is a language profile based on existing W3C XML vocabularies and
CSS modules. These provide standard mechanisms for representing Web page
structure, presentation and form interaction. The DIAL also makes use of
the DISelect metadata vocabulary ("Content Selection for Device
Independence -- DISelect") for overcoming the authoring challenges
("Authoring Challenges for Device Independence") inherent in authoring
for multiple delivery contexts. The DIAL Primer summarizes the concept
of device independence, the scenarios in which it could be used, and
the considerations in order to achieve that goal. It then describes the
role of DIAL in ensuring the delivery of content suitable for the user,
device and inherent circumstances in which it was requested. DIAL
facilitates writing a Web page that can be presented by a range of
devices, with differing capabilities and states; and consumed by users
with differing preferences and entitlements (such varying conditions
are illustrated in 'Delivery context characteristics'). This is achieved
by allowing authors to declare authorial intent as to the conditions
under which content should be chosen or filtered. When a request is made
for a DIAL document, it must pass through at least one DIAL processor
before being presented to the requesting user. DIAL processors may exist
at any of the server, optional intermediary adaptation, or client layers.
Their role is to determine whether to select or filter out blocks of
content marked up with DISelect expressions. The evaluation of these
expressions requires the processor to query the Delivery Context so
that the decision to select or filter content involves the specific
conditions under which the request was made. After all DIAL processing
is complete, all content selections will have been resolved. Since
DIAL implements XHTML 2.0 metadata extensions, it allows other metadata
standards to be plugged in to allow content to be selected or excluded
for rendering based on variable business rules. These could include
flagging the nature of the content (such as erotic or violent), or by
indicating that it should only be shown in a certain location or time
of day. W3C's Ubiquitous Web Applications Working Group was chartered
through March 31, 2009, seeking to simplify the creation of distributed
Web applications involving a wide diversity of devices, including
desktop computers, office equipment, home media appliances, mobile
devices (phones), physical sensors and effectors (including RFID and
barcodes). Click Here
Thursday, November 1, 2007
XML Schema for ENUM Validation Token Format Definition
Members of the IETF Telephone Number Mapping (ENUM) Working Group have
released an updated "ENUM Validation Token Format Definition" draft
specification. An ENUM domain name is tightly coupled with the underlying
E.164 number. The process of verifying whether the Registrant of an
ENUM domain name is identical to the Assignee of the corresponding
E.164 number is commonly called "validation". This document describes
an signed XML data format (the Validation Token) with which Validation
Entities can convey successful completion of a validation procedure in
a secure fashion. According to the data model requirements, the Token
is the only piece of data passed from the VE to the Registry. Therefore,
the Token needs to contain as least as much information as the Registry
requires to grant the delegation of the requested ENUM domain according
to its registration policy. As the Token will be included in XML-based
Registry/Registrar protocols like the Extensible Provisioning Protocol
(EPP) it is a natural choice to use XML to encode Validation Tokens.
According to the architecture model the propriety of an ENUM delegation
depends on the trust relationship between the Registry and the VE. In
general, an untrusted link between Registry and VE should be assumed
(for instance the Token is passed along with the registration request
by a Registrar, who might have no role in asserting the right-to-use).
Therefore, the Token must be protected against forgery, tampering and
replay-attacks. The cryptographic signature on the token follows RFC
3275 (XML-DSIG. As tokens might be transmitted as part of an already
XML based protocol the exclusive XML canonicalization must be used.
This transform guarantees that namespace declarations inherited from
the surrounding XML do not invalidate the signature. In order to make
the signature an integral part of the token the "enveloped"-signature
mode is employed. The signature covers all information contained in the
Token. The Validation Token is structured into three parts: the basic
validation information, additional information about the Registrant,
and the digital signature. The XML schema can be found in Section 6
of the document. More Information See also the IETF Telephone Number Mapping (ENUM) Working Group Charter: Click Here
released an updated "ENUM Validation Token Format Definition" draft
specification. An ENUM domain name is tightly coupled with the underlying
E.164 number. The process of verifying whether the Registrant of an
ENUM domain name is identical to the Assignee of the corresponding
E.164 number is commonly called "validation". This document describes
an signed XML data format (the Validation Token) with which Validation
Entities can convey successful completion of a validation procedure in
a secure fashion. According to the data model requirements, the Token
is the only piece of data passed from the VE to the Registry. Therefore,
the Token needs to contain as least as much information as the Registry
requires to grant the delegation of the requested ENUM domain according
to its registration policy. As the Token will be included in XML-based
Registry/Registrar protocols like the Extensible Provisioning Protocol
(EPP) it is a natural choice to use XML to encode Validation Tokens.
According to the architecture model the propriety of an ENUM delegation
depends on the trust relationship between the Registry and the VE. In
general, an untrusted link between Registry and VE should be assumed
(for instance the Token is passed along with the registration request
by a Registrar, who might have no role in asserting the right-to-use).
Therefore, the Token must be protected against forgery, tampering and
replay-attacks. The cryptographic signature on the token follows RFC
3275 (XML-DSIG. As tokens might be transmitted as part of an already
XML based protocol the exclusive XML canonicalization must be used.
This transform guarantees that namespace declarations inherited from
the surrounding XML do not invalidate the signature. In order to make
the signature an integral part of the token the "enveloped"-signature
mode is employed. The signature covers all information contained in the
Token. The Validation Token is structured into three parts: the basic
validation information, additional information about the Registrant,
and the digital signature. The XML schema can be found in Section 6
of the document. More Information See also the IETF Telephone Number Mapping (ENUM) Working Group Charter: Click Here
Public Review: Web Services for Remote Portlets Specification v2.0
OASIS announced the publication of a Second Public Review Draft for
"Web Services for Remote Portlets Specification v2.0." The review
ends on 15-November-2007. This specification is the effort of the
OASIS Web Services for Remote Portlets (WSRP) Technical Committee
which aims to simplify the effort required of integrating applications
to quickly exploit new web services as they become available. Integration
of remote content and application logic into an End-User presentation
has been a task requiring significant custom programming effort.
Typically, vendors of aggregating applications, such as a portal,
write special adapters for applications and content providers to
accommodate the variety of different interfaces and protocols those
providers use. The goal of this specification is to enable an
application designer or administrator to pick from a rich choice of
compliant remote content and application providers, and integrate
them with just a few mouse clicks and no programming effort. This
revision of the specification adds Consumer managed coordination,
additional lifecycle management and a set of related aggregation
enhancements. The standard layers on top of the existing web services
stack, utilizing existing web services standards and will leverage
emerging web service standards (such as policy) as they become
available. The interfaces defined by this specification use the Web
Services Description Language (WSDL). Scenarios that motivate WSRP
functionality include: (1) Content hosts, such as portal servers,
providing Portlets as presentation-oriented web services that can be
used by aggregation engines. (2) Aggregating frameworks, including
portal servers, consuming presentation-oriented web services offered
by content providers and integrating them into the framework. Many
of the non-portal use cases were originally defined by the Web
Services for Interactive Applications (WSIA) OASIS Technical Committee.
The WSIA use cases have become input to the ongoing effort in this
area by the WSRP OASIS Technical Committee. More Information
"Web Services for Remote Portlets Specification v2.0." The review
ends on 15-November-2007. This specification is the effort of the
OASIS Web Services for Remote Portlets (WSRP) Technical Committee
which aims to simplify the effort required of integrating applications
to quickly exploit new web services as they become available. Integration
of remote content and application logic into an End-User presentation
has been a task requiring significant custom programming effort.
Typically, vendors of aggregating applications, such as a portal,
write special adapters for applications and content providers to
accommodate the variety of different interfaces and protocols those
providers use. The goal of this specification is to enable an
application designer or administrator to pick from a rich choice of
compliant remote content and application providers, and integrate
them with just a few mouse clicks and no programming effort. This
revision of the specification adds Consumer managed coordination,
additional lifecycle management and a set of related aggregation
enhancements. The standard layers on top of the existing web services
stack, utilizing existing web services standards and will leverage
emerging web service standards (such as policy) as they become
available. The interfaces defined by this specification use the Web
Services Description Language (WSDL). Scenarios that motivate WSRP
functionality include: (1) Content hosts, such as portal servers,
providing Portlets as presentation-oriented web services that can be
used by aggregation engines. (2) Aggregating frameworks, including
portal servers, consuming presentation-oriented web services offered
by content providers and integrating them into the framework. Many
of the non-portal use cases were originally defined by the Web
Services for Interactive Applications (WSIA) OASIS Technical Committee.
The WSIA use cases have become input to the ongoing effort in this
area by the WSRP OASIS Technical Committee. More Information
Geospatial Vocabulary and Geospatial Ontologies Incubator Group Reports
Members of the W3C Geospatial Incubator Group (GeoXG) have published
their Incubator Group Reports on "W3C Geospatial Vocabulary" and "W3C
Geospatial Ontologies." The Incubator's work has been greatly influenced
by the work of the Open Geospatial Consortium (OGC), ISO/TC 211, and georss The Incubator has followed the lead of GeoRSS in seeking
to complement those efforts with a simpler baseline implementation of
geospatial resource description for the Web. The Vocabulary Report
defines a basic ontology and OWL vocabulary for representation of
geospatial properties for Web resources. Specifically, it (1) discusses
the need for updating the W3C 2003 geo vocabulary; (2) presents a model
for basic feature properties of Web resources; (3) presents realizations
of these feature property elements as XML and as OWL/RDF vocabularies;
(4) describes use of the XML elements in Web feeds such as RSS and Atom.
The Ontologies Report supplies an overview and description of geospatial
foundation ontologies to represent geospatial concepts and properties
for use on the Worldwide Web. Background: "Issues in geographical
representation are many and often parallel those in the Web as a whole,
from resource identifiers to machine-readable semantics. Just as there
are both physical (IP) and conceptual (domain namespace) locators on
the World Wide Web, there are physical (latitude-longitude coordinates
and street addresses) and conceptual (placenames and political divisions)
locators on the Local Web. Geospatial concepts and relationships are
at once as possible and difficult to define with formal semantics as
those which express any other resource meaning. Geospatial aspects of
progress from the Web of text and tags to the Semantic Web are just
as challenging and important." The W3C Geospatial Incubator Group,
part of W3C's Incubator Activity, was chartered to begin addressing
issues of location and geographical properties of resources for the Web
of today and tomorrow, by taking a concrete step to update the W3C GEO
vocabulary, laying the groundwork for a more comprehensive geospatial
ontology, and formulating a proposal for a W3C Local Web working group
to develop recommendations to further the Local Web. Sponsoring Members
inclide the Open Geospatial Consortium, SRI. USC ISI, Stanford
University, and Oracle Corporation. More Information See also the Ontology Report: Click Here
their Incubator Group Reports on "W3C Geospatial Vocabulary" and "W3C
Geospatial Ontologies." The Incubator's work has been greatly influenced
by the work of the Open Geospatial Consortium (OGC), ISO/TC 211, and georss The Incubator has followed the lead of GeoRSS in seeking
to complement those efforts with a simpler baseline implementation of
geospatial resource description for the Web. The Vocabulary Report
defines a basic ontology and OWL vocabulary for representation of
geospatial properties for Web resources. Specifically, it (1) discusses
the need for updating the W3C 2003 geo vocabulary; (2) presents a model
for basic feature properties of Web resources; (3) presents realizations
of these feature property elements as XML and as OWL/RDF vocabularies;
(4) describes use of the XML elements in Web feeds such as RSS and Atom.
The Ontologies Report supplies an overview and description of geospatial
foundation ontologies to represent geospatial concepts and properties
for use on the Worldwide Web. Background: "Issues in geographical
representation are many and often parallel those in the Web as a whole,
from resource identifiers to machine-readable semantics. Just as there
are both physical (IP) and conceptual (domain namespace) locators on
the World Wide Web, there are physical (latitude-longitude coordinates
and street addresses) and conceptual (placenames and political divisions)
locators on the Local Web. Geospatial concepts and relationships are
at once as possible and difficult to define with formal semantics as
those which express any other resource meaning. Geospatial aspects of
progress from the Web of text and tags to the Semantic Web are just
as challenging and important." The W3C Geospatial Incubator Group,
part of W3C's Incubator Activity, was chartered to begin addressing
issues of location and geographical properties of resources for the Web
of today and tomorrow, by taking a concrete step to update the W3C GEO
vocabulary, laying the groundwork for a more comprehensive geospatial
ontology, and formulating a proposal for a W3C Local Web working group
to develop recommendations to further the Local Web. Sponsoring Members
inclide the Open Geospatial Consortium, SRI. USC ISI, Stanford
University, and Oracle Corporation. More Information See also the Ontology Report: Click Here
Converting XML Schemas to Schematron, Part 5: Validating Your Own
This Part 5 article installment continues a serialized article on
"Converting XML Schemas to Schematron." The author explained some
reasons for wanting to convert XSD to Schematron in Part 1: (1) better
diagnostics -- grammar-based diagnostics basically don't work; (2)
Schematron only needs an XSLT implementation. From Part 5: "XSD
allows you to derive your own simple datatypes by restricting the
lexical space or the value space of the type. The rule about derivation
by restriction is that everything that is valid against the derived
type is also valid against the base type. Type derivation by restriction
can be directly implemented by Schematron abstract rules. There is a
mismatch in terminology: we restrict the type (in the XSD) by extending
the constraints (in Schematron). We are not implementing simple type
derivation by union or list at the moment, because it is outside our
primary requirements. I expect derivation by list would benefit from
XPath2's extra power. Derivation by union needs more thought. But at
least this puts us in the position where I think... we can say that
Schematron's power to validate datatypes is strictly more power than
XSDs power for datatypes derived by restriction; Schematron (i.e.
using Xpath2) can express all the XSD constraints and more. But is
Schematron more powerful to model type derivation? We want to be able
to draw pretty diagrams of type derivation. Well, actually because
derivation by restriction is simply implemented by abstract rules, in
fact Schematron is equally capable of modeling the derivation structure. More Information See also XML Schema Languages: Click Here
"Converting XML Schemas to Schematron." The author explained some
reasons for wanting to convert XSD to Schematron in Part 1: (1) better
diagnostics -- grammar-based diagnostics basically don't work; (2)
Schematron only needs an XSLT implementation. From Part 5: "XSD
allows you to derive your own simple datatypes by restricting the
lexical space or the value space of the type. The rule about derivation
by restriction is that everything that is valid against the derived
type is also valid against the base type. Type derivation by restriction
can be directly implemented by Schematron abstract rules. There is a
mismatch in terminology: we restrict the type (in the XSD) by extending
the constraints (in Schematron). We are not implementing simple type
derivation by union or list at the moment, because it is outside our
primary requirements. I expect derivation by list would benefit from
XPath2's extra power. Derivation by union needs more thought. But at
least this puts us in the position where I think... we can say that
Schematron's power to validate datatypes is strictly more power than
XSDs power for datatypes derived by restriction; Schematron (i.e.
using Xpath2) can express all the XSD constraints and more. But is
Schematron more powerful to model type derivation? We want to be able
to draw pretty diagrams of type derivation. Well, actually because
derivation by restriction is simply implemented by abstract rules, in
fact Schematron is equally capable of modeling the derivation structure. More Information See also XML Schema Languages: Click Here
XML Schema Patterns for Databinding: Updated W3C Working Drafts
Members of the W3C XML Schema Patterns for Databinding Working Group
have published updated Working Drafts for "Basic XML Schema Patterns
for Databinding Version 1.0" and "Advanced XML Schema Patterns for
Databinding Version 1.0." The document represent the result of the first
call for implementations, the initial results that led to the
modifications of this specification are available for the new
classification of basic, advanced tests. A complete report is also
available. The patterns can describe XML 1.0 representations of commonly
used data structures independent of any particular programming language,
database or modelling environment. Reviewers are invited to contribute
to the test suite and read the interoperability report and about Web
services. Background: A representative collection of databinding
implementations in common use was compiled to provide an indication of
the "state of the art." It displayed uneven and inconsistent support
of the W3C XML Schema 1.0 Recommendation resulting in impaired
interoperability and a poor user experience of databinding tools. For
example (1) rejecting valid XML Schema 1.0 documents, (2) rejecting
valid XML 1.0 instance documents, and (3) making the content of valid
XML 1.0 instance documents unavailable in mapped data structures. The
W3C XML Schema Patterns for Databinding Working Group was chartered to
"define a set of XML Schema patterns that will be efficiently implementable
by the broad community who use XML databindings. Patterns which may prove
useful to model include abstractions of structures common across a wide
variety of programming environments, such as hash tables, vectors, and
collections. There are several ways of representing such abstracted data
structures and Web Services toolkits are currently using ad hoc
technologies to infer the most suitable language mapping when processing
XML Schemas. Agreeing on a set of XML Schema patterns for which
databinding optimizations can be made will facilitate the ability of Web
services and other toolkits to expose a more comprehensible data model
to the developer." More Information See also the XML Schema Patterns for Databinding Interoperability Report: Click Here
have published updated Working Drafts for "Basic XML Schema Patterns
for Databinding Version 1.0" and "Advanced XML Schema Patterns for
Databinding Version 1.0." The document represent the result of the first
call for implementations, the initial results that led to the
modifications of this specification are available for the new
classification of basic, advanced tests. A complete report is also
available. The patterns can describe XML 1.0 representations of commonly
used data structures independent of any particular programming language,
database or modelling environment. Reviewers are invited to contribute
to the test suite and read the interoperability report and about Web
services. Background: A representative collection of databinding
implementations in common use was compiled to provide an indication of
the "state of the art." It displayed uneven and inconsistent support
of the W3C XML Schema 1.0 Recommendation resulting in impaired
interoperability and a poor user experience of databinding tools. For
example (1) rejecting valid XML Schema 1.0 documents, (2) rejecting
valid XML 1.0 instance documents, and (3) making the content of valid
XML 1.0 instance documents unavailable in mapped data structures. The
W3C XML Schema Patterns for Databinding Working Group was chartered to
"define a set of XML Schema patterns that will be efficiently implementable
by the broad community who use XML databindings. Patterns which may prove
useful to model include abstractions of structures common across a wide
variety of programming environments, such as hash tables, vectors, and
collections. There are several ways of representing such abstracted data
structures and Web Services toolkits are currently using ad hoc
technologies to infer the most suitable language mapping when processing
XML Schemas. Agreeing on a set of XML Schema patterns for which
databinding optimizations can be made will facilitate the ability of Web
services and other toolkits to expose a more comprehensible data model
to the developer." More Information See also the XML Schema Patterns for Databinding Interoperability Report: Click Here
Subscribe to:
Posts (Atom)