Cover Pages: XML Daily Newslink: Tuesday, 02 February 2010

A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS and Sponsor Members
Edited by Robin Cover

This issue of XML Daily Newslink is sponsored by:
Microsoft Corporation http://www.microsoft.com

Headlines

RDFa Working Group to Support Embedding Structured Data in Web Documents
Public Review: Biometric Identity Assurance Services (BIAS) SOAP Profile
IETF KEYPROV Working Group Updates Symmetric Key Package Content Type
SOA Practioners Should Define Standards First
CSDL: Conceptual Schema Definition Language
For Release: Apache Xerces-C++ 3.1.0 Validating XML Parser
UC4 Software Unveils Agent to Automate SOA and Cloud Computing

RDFa Working Group to Support Embedding Structured Data in Web Documents
Staff, W3C Announcement

W3C has announced the creation of a new RDFa Working Group to support the developing use of RDFa for embedding structured data in Web documents in general. RDFa Version 1.0, RDFa in XHTML: Syntax and Processing: A Collection of Attributes and Processing Rules for Extending XHTML to Support RDF (W3C Recommendation of October 14, 2008) specifies attributes to express structured data in any markup language.

"The new RDFa Working Group will publish W3C Recommendations to extend and enhance the currently published RDFa 1.0 documents, including an API. The Working Group will also support the HTML Working Group in its work on incorporating RDFa in HTML5 and XHTML5—as a followup on the the currently published Working Draft for RDFa 1.0 in HTML5.

The main directions of RDFa's enhancements are: (1) specification of an API for RDFa, usable for browsers and XML applications; (2) updates to the RDFa language that ease the practice of authoring RDFa; (3) definition of the semantics of RDFa attributes for XML languages in general. The goal is to maintain backward compatibility with RDFa 1.0, although some small non-compatible changes with regard to the defaults on XML Literals, may be introduced. No radical redefinition of the RDFa language is envisaged.

Backwards compatibility with RDFa 1.0 is of great importance. That means, in general, that all triples that are produced via the October 2008 version of RDFa, should still be generated in the new version. For each new feature, if there is doubt or a perceived problem with respect to this, the guideline should be to not include the feature in the set of modifications. The only minor feature the Working Group has identified and which may constitute a possible exception to this rule, is the default XML Literal generation..."

Public Review: Biometric Identity Assurance Services (BIAS) SOAP Profile
Matthew Swayze and Cathy Tilton (eds), OASIS Public Review Draft

Members of the OASIS Biometric Identity Assurance Services (BIAS) Integration Technical Committee have released an approved Committee Draft of Biometric Identity Assurance Services (BIAS) SOAP Profile, Version 1.0 for public review through March 31, 2010. The document specifies a SOAP profile that implements the BIAS abstract operations specified in INCITS 442 as SOAP messages. The specification presents the design concepts and architecture for invoking SOAP-based services that implement BIAS operations; presents the namespaces necessary to implement this profile, INCITS BIAS data elements, and identifies relationships to external data definitions; specifies the content of the BIAS messages; presents the BIAS message structure, as well as rules and considerations for its application; presents information on error handling; specifies conformance requirements. Annexes include the OASIS BIAS XML schema/sample Web Service Definition Language (WSDL), use cases, sample code, acknowledgements, and the revision history of this profile

The OASIS BIAS Integration TC complements the efforts of the InterNational Committee for Information Technology Standards (INCITS) to provide the biometrics and security industries with a documented, open framework for deploying and invoking identity assurance capabilities that can be readily accessed as services. The OASIS BIAS Integration TC defines and describes methods and bindings by which the INCITS BIAS framework can be used within XML-based transactional Web services and service-oriented architectures.

In late 2005/early 2006, a gap was identified in the existing biometric standards portfolio with respect to biometric services. The Biometric Identity Assurance Services standard proposal was for a collaborative effort between government and private industry to provide a services-based framework for delivering identity assurance capabilities, allowing for platform and application independence. This standard proposal required the attention of two major technical disciplines: biometrics and service architectures. The expertise of both disciplines was required to ensure the standard was technically sound, market relevant, and achieved widespread adoption. The International Committee for Information Technology Standards (INCITS) M1 provided the standards leadership relevant to biometrics, defining the taxonomy of biometric operations and data elements. OASIS provided the standards leadership relevant to service architectures with an initial focus on web services, defining the schema and SOAP messaging.

The driving requirements of the BIAS standard proposal were to provide the ability to remotely invoke biometric operations across an SOA infrastructure; to provide business level operations without constraining the application/business logic that implements those operations; to be as generic as possible—technology, framework, and application domain independent; and to provide basic capabilities that can be used to construct higher level, aggregate/composite operations.

IETF KEYPROV Working Group Updates Symmetric Key Package Content Type
Sean Turner and Russ Housley (eds), IETF Internet Draft

Members of the IETF Provisioning of Symmetric Keys (KEYPROV) Working Group have published an updated I-D for Symmetric Key Package Content Type. This is one of three specifications being progressed to support the goal of provisioning symmetric keys and associated attributes dynamically to already issued devices such as cell phones and USB drives. The KEYPROV Working Group was chartered in recognition of "the need for provisioning protocols in PKI architectures; in particular the ability to provision symmetric keys and associated attributes dynamically to already issued devices such as cell phones and USB drives is highly desirable. The working group is developing the necessary protocols and data formats required to support provisioning and management of symmetric key authentication tokens, both proprietary and standards based."

The Symmetric Key Package Content Type specification "defines the symmetric key format content type. It is transport independent. The Cryptographic Message Syntax (RFC 5652) can be used to digitally sign, digest, authenticate, or encrypt this content type. The uses cases that motivated this work are elaborated in "Portable Symmetric Key Container (PSKC). Symmetric Key Package Content Type: The symmetric key package content type is used to transfer one or more plaintext symmetric keys from one party to another. A symmetric key package may be encapsulated in one or more CMS protecting content types. This content type must be Distinguished Encoding Rules (DER) encoded, per X.690...

Several attributes are defined to assist those using the symmetric key package defined in this document as part of a Portable Symmetric Key Container protocol (PSKC). The attributes fall in to three categories. The first category includes attributes that apply to a key package, and these attributes will generally appear in sKeyPkgAttrs. The second category includes attributes that apply to a particular key, and these attributes will generally appear in sKeyAttrs. The third category includes attributes that apply to a key policy. Of the attributes defined next, only the Key Identifier and Algorithm key attributes MUST be included. All other attributes are OPTIONAL. Like PSKC, the Symmetric Key Content Type supports extensibility. Primarily this is accomplished through the definition and inclusion of new attributes, but in some instances where the attribute contains more than one type the ASN.1 "..." extensibility mechanism is employed. A straightforward approach to conversion from XML types to ASN.1 is employed... Section 3.3 presents the Key Policy Attributes: Key policy attributes indicate a policy that can be attached to a key (e.g., Start Date, Expiry Date, Number of Transactions, Key Usage, PIN Policy). Appendix A (ASN.1 Module) appendix provides the normative ASN.1 definitions for the structures described in the specification using ASN.1 as defined in X.680 through X.683 (Extensible Markup Language (XML) element and attributes as defined in PSKC..."

SOA Practioners Should Define Standards First
Mark Little, InfoQueue

"Over the years we have had a number of articles and presentations on standards related activities as they relate to SOA, Web Services and REST. Most agree that standards are important to prevent vendor lock-in and try to ensure interoperability between heterogeneous implementations. However, recently Steve Jones has raise an important issue to do with when standards should be used in the SOA lifecycle. As he says, it 'stuns' him that developers, business stake-holders etc. do not define the standards they need to use at the very start. As far as technical standards are concerned (e.g., WS-*), Steve believes that there are few good excuses for not defining these at the start...

Jones: "Starting with the business architecture that means picking your approach to defining the business services. Now you could use my approach or something else but what ever you do it needs to be consistent across the project and across the enterprise if you are doing a broader transformation programme. On requirements its about structuring those requirements against the business architecture and having a consistent way of matching the requirements against the services and capabilities so you don't get duplication. These elements are about people processes and documentation and they really aren't hard to set up and its very important that you do this so your documentation is in a consistent format that flows through to delivery and operations...

Saying 'but its REST' and claiming that everything will be dynamic is a cop-out and it really just means you are lazy. So in the REST world what you need to do is (1) Agree how you are going to publish the specifications to the resources, how will you say what a 'GET' does and what a 'POST' does; (2) Create some exemplar 'services'/resources with the level of documentation required for people to use them; (3) Agree a process around Mocking/Proxying to enable people to test and verifying their solutions without waiting for the final solution; (4) Agree the test process against the resources and how you will verify that they meet the fixed requirements of the system at that point in time... This last one is important..."

CSDL: Conceptual Schema Definition Language
Rick Jelliffe, O'Reilly Technical

"CSDL (Conceptual Schema Definition Language) is the schema language available under the OSP of the ODP (Open Data Protocol). ODP is a technology that originated at Microsoft and is spreading from there...

When we look at schema languages, there are three basic issues, even though usually schema languages don't present themselves as functions, but as equations which some data will satisfy: [i] What is the input data structure? [ii] What kind of grammar is the schema language? [iii] What is the output data structure? Viz., Is the schema language defined as a recognizer or transducer?

For example, in RELAX NG the input is an attribute-value tree (XML), the grammar is regular (and ambiguous), and the output is a boolean (valid or invalid.) Of course, an application is free to produce richer information as the output of validation, but it is not in the standard. Schematron's default, in contrast, is that the input is an XPath Data Model (a directed coloured rooted graph, a path-rich XML), the grammar is context-free (because of XPath variables and 'current()'), and the output is an XML attribute-value tree (i.e., SVRL). XSD's input data structure is an attribute-value tree (XML), the grammar is regular (and non-ambiguous: the famous UPA for example), and the output is a non-XML tree (PSVI). CSDL's input data structure is a multi-rooted, directed, possibly cyclic graph: in particular, the Entity Data Model: entities and associations; the grammar is regular, and the output is not defined. However, it seems that can be used for serialization, for validation and for data import back into an RDBMS.

From the 'dsdl-discuss' list posting: "I think WG1 should consider Conceptual Schema Definition Language (CSDL) as part of DSDL. It covers modeling entity-relational data in particular. I suspect it does the kind of thing we might have wanted part 6 Path-based integrity constraints to do, but simpler and more directly. It also provides a data type system that is in between XSD data types and just using primitives: this might be more appealing for RELAX NG and implementers. It is implemented by Microsoft and IBM. It has been out for a year, and just recently made it to CSDL 1.0. It covers an area DSDL does not cover well at the moment, but which is a very important area. In fact, I don't think XSD key/keyref covers this area well. It is reasonably small and simple. Note that it is not a general purpose schema language: it does impose some constraints, in that it requires one or more branches without being able to specify a root element; I think that is OK, because it makes the distinction between CSDL and RELAX NG or Schematron clearer..."

For Release: Apache Xerces-C++ 3.1.0 Validating XML Parser
Boris Kolpackov, XML-DEV Posting

The Xerces-C++ developer community has announced the availability of Apache Xerces-C++ 3.1.0. Xerces-C++ is an open-source, validating XML parser written in a portable subset of C++. It provides DOM (level 1, 2, and 3), SAX, and SAX2 APIs and supports validation of XML documents against DTDs and XML Schema.

This version includes a number of new features, performance improvements and a large number of bug fixes, especially in the XML Schema spec conformance area, including: (1) Support for handling multiple XML Schema import declarations with the same target namespace; (2) Support for configuration of the parser buffer low water mark; (3) DOMLSParser::parseWithContext implementation; (4) Improved XML Schema performance and reduced memory footprint when validating with large maxOccurs values; if available, the SSE2 instructions are used to further speedup this case; (5) Improved scalability of the XML Schema identity checking—key, keyref, and unique; (6) More robust external library detection—libcurl and ICU: (7) Compilation of the ICU message loader resources no longer depends on the ICU implementation details.

This release has been tested on all major platforms and comes with precompiled libraries (total 16) for various CPU architectures, operating systems, and C++ compilers. For most platforms 32-bit and 64-bit variants are provided.

Summary: "Xerces-C++ is a validating XML parser written in a portable subset of C++. Xerces-C++ makes it easy to give your application the ability to read and write XML data. A shared library is provided for parsing, generating, manipulating, and validating XML documents using the DOM, SAX, and SAX2 APIs. For an introduction to programming with Xerces-C++ refer to the Programming Guide. Xerces-C++ is faithful to the XML 1.0 recommendation and many associated standards... The parser provides high performance, modularity, and scalability. Source code, samples and API documentation are provided with the parser. For portability, care has been taken to make minimal use of templates, no RTTI, and minimal use of #ifdefs..."

See also: the Xerces-C++ web site

UC4 Software Unveils Agent to Automate SOA and Cloud Computing
Staff, UC4 Announcement

"UC4 Software, a leading provider of Intelligent Service Automation and IT process optimization solutions, has announced the UC4 Agent for Web Services. The new agent initiates and manages Web service-enabled jobs as part of background processing and enables customers to extend the benefits of automation into SOA and cloud environments.

The UC4 Agent for Web Services allows customers to bring the cost savings benefits of automation to SOA and the cloud, reduce risks in modernization projects, and extend automation to Web service-enabled applications and tools. With an intuitive user interface for rapid execution, the UC4 Agent for Web Services supports WSDL and SOAP, and virtually eliminates the need for manual coding and command lines...

UC4 V8 combines classical job scheduling, conditional business processing, and an awareness of application data and drive your business' processing based on calendars, events, dynamic data changes, message queues, database triggers, file arrivals, thresholds, resource availability and more..."

See also: the ADT Magazine article


SEARCH \| ABOUT \| INDEX \| NEWS \| CORE STANDARDS \| TECHNOLOGY REPORTS \| EVENTS \| LIBRARY

Headlines

Sponsors