Cover Pages: XML Daily Newslink: Wednesday, 19 November 2008

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:
IBM Corporation http://www.ibm.com

Headlines

Call for Review: Scalable Vector Graphics (SVG) Tiny 1.2 Specification
The Abstract User Interface Markup Language Web Toolkit
HELD Identity Extensions
What's Allowed in a URI?
Nuxeo Supports OASIS in CMIS Standardization
Referential Integrity and XML Data
Schemas: Stereotypes, Archetypes or Prototypes?

Call for Review: Scalable Vector Graphics (SVG) Tiny 1.2 Specification
Ola Andersson, Robin Berjon (et al., eds), W3C Technical Report

W3C's SVG Working Group has published the Proposed Recommendation for the "Scalable Vector Graphics (SVG) Tiny 1.2 Specification." The SVG Working Group plans to submit this specification for consideration as a W3C Recommendation, having demonstrated multiple interoperable implementations for each test in the SVG Tiny 1.2 test suite, with at least one of the passing implementations on a mobile platform. The SVG Working Group, working closely with the developer community, has produced an implementation report to prove the implementability of this specification. The Candidate Recommendation and Last Call Working Draft phases for this specification resulted in a number of comments which have been addressed by the SVG Working Group, with a Disposition of Comments available on the W3C SVG site. Comments are welcome through December 15, 2008. Scalable Vector Graphics (SVG) Tiny, Version 1.2 is a language for describing two-dimensional vector and mixed vector/raster graphics in XML. Its goal is to provide the ability to create a whole range of graphical content, from static images to animations to interactive Web applications. SVG 1.2 Tiny is a profile of SVG intended for implementation on a range of devices, from cellphones and PDAs to desktop and laptop computers, and thus includes a subset of the features included in SVG 1.1 Full, along with new features to extend the capabilities of SVG. Further extensions are planned in the form of modules which will be compatible with SVG 1.2 Tiny, and which when combined with this specification, will match and exceed the capabilities of SVG 1.1 Full.

The Abstract User Interface Markup Language Web Toolkit
Marco Lerro, Roberto Longobardi (et al.), IBM developerWorks

The Abstract User Interface Markup Language (AUIML) Web Toolkit (AWT) makes it possible to develop Web 2.0 interfaces quickly and easily by merging the ease-of-use and expressiveness of the AUIML visual designer with the versatility of the Dojo toolkit. Rapid development of user interfaces is made possible thanks to the AUIML visual editor and also because of the availability of a number of ready-to-use patterns. Experience has shown that the combination of these two factors provide a significant increase in productivity, and this is even more true considering the fact that, currently, there is no comparable technology that targets a Dojo interface. One of the most common tasks in user interface design is the creation of input forms, that is, panels that collect data from the user. Over the years, a number of tools have been created to make this job easier for designers and developers, and the AUIML Toolkit is one of these tools. The AUIML Toolkit consists of an Eclipse-based Visual Builder and both a Java Swing renderer and a Web renderer. When designing, developers used the Visual Builder to create the panels, testing them through the preview of the two runtime renderers.

HELD Identity Extensions
James Winterbottom, Martin Thomson (et al., eds), IETF Internet Draft

Members of the IETF Geographic Location/Privacy (GEOPRIV) Working Group have released an updated Internet Draft for the "HELD Identity Extensions" specification. "When a Location Information Server receives a request for location information (using the locationRequest message), described in the base HTTP Enabled Location Delivery (HELD) specification, it uses the source IP address of arriving message as a pointer to the location determination process. This is sufficient in environments where an Target's location can be determined based on its IP address. Two additional use cases are addresses by this document. In the first, the source IP address in the request is not the only identifier for the Target. In the second, an entity other than the Target requests the Target's location. This document extends the HELD protocol to allow the location request message to carry additional identifiers assisting the location determination process. It defines a set of URIs for Target identifiers and an XML containment schema. This extension is used in conjunction with HELD to provide Target identification, and set of criteria of when to use this extensions are provided. Examples and usage in HELD message syntax are also shown.

What's Allowed in a URI?
James Clark, Random Thoughts Blog

Java 1.4 introduced the java.net.URI which provides RFC 2936-compliant URI handling. I thought I should try to fix Jing and Trang to use this. So I've been looking through all the relevant specifications to figure out to what extent I can leave things to java.net.URI. It's convenient to begin with XLink. Section 5.4 requires the value of the HREF attribute to be a URI reference after certain characters that are disallowed by RFC 2396 are escaped. These are described as all non-ASCII characters, plus the excluded characters listed in Section 2.4 of IETF RFC 2396, except for the number sign (#) and percent sign (%) and the square bracket characters re-allowed in IETF RFC 2732. If we look at 2.4.3 of RFC 2396 (why does XLink reference section 2.4 rather than 2.4.3?), we see the following sets of characters excluded: [control, space, delims, unwise]... Section 3 of RFC 2732 (which modifies RFC 2396 to handle IPv6 addresses) does indeed allow square brackets by removing them from the 'unwise' set. Putting these all together, we can distinguish the following categories of characters that are allowed by XLink but not allowed by RFC 2396/RFC 2732 [list]... Looking at the various XML-related specs, things seem to be nicely aligned... Finally we are ready to look at java.net.URI. This allows URIs to contain an additional set of "other" characters which consist of non-ASCII characters with the exception of [...] This means that if you want to give an LEIRI such as an XML system identifier to java.net.URI you first need to percent encode any of the following [...] Note that you don't want to blindly percent encode all non-ASCII characters because that will unnecessarily make IRIs containing non-ASCII characters unintelligible to humans...

Nuxeo Supports OASIS in CMIS Standardization
Staff, Announcement

Nuxeo, independent software vendor and creator of the ECM open source platform, announces its membership in the OASIS standardization consortium. Nuxeo will participate in the definition of the future CMIS standard known as the Content Management Interoperability Standard. This membership follows upon the very positive response of Nuxeo to the presentation of CMIS in September 2008. Nuxeo's implementation prototype of the current draft of CMIS is in progress, and it will be available in December, 2008. This release will be concurrent with the next release of Nuxeo platform. Stefan Fermigier, founder and chairman of Nuxeo, stated: "For a long time now one of the main considerations of IT management is that interoperability is seen as a means to reduce risks and costs, speed up deployments, and to be free from limitations inherent to ISVs. By actively supporting CMIS, Nuxeo renews its commitment to work with other ISVs, participates in an innovative ecosystem, and helps its customers to reduce costs in these times of economic troubles." Eric Barroca, Nuxeo's Executive VP, Operations noted that "the Nuxeo Platform is perfectly adapted for an API access such as CMIS, which already uses concepts that are standard for Nuxeo. The advanced functions of our platform, such as versioning, complex searches, and correlation, will be available via CMIS, making those functions accessible to a vast range of content creation, editing or processing applications, all within the enterprise information system." Note also: Nuxeo Developer Day ['Building a World-Class ECM Platform'] in Paris, part of the Open World Forum event in Paris (December 01, 2008). Presentations will include a session on interoperability, including the emerging CMIS standard. 'Standards and interoperability for ECM: JCR2, CMIS', with Florent Guillaume (Head of R&D, Nuxeo) and John Newton (Founder and CTO, Alfresco).

See also: CMIS references

Referential Integrity and XML Data
Conor O'Mahony, Blog

Referential integrity is a relational database feature that ensures consistency is maintained between items that reference one another. For instance, if you have a database table with order information that refers to a database table with product information, referential integrity ensures that each order refers to a valid product. In technical terms, referential integrity ensures that each product ID specified in the order table (where the product ID is a foreign key in the order table), exists in the product table. Over the years, DBAs have found referential integrity to be a valuable feature in their relational databases. And now, they are asking how to ensure referential integrity with XML data. The XML standard does not include mechanisms for ensuring referential integrity amongst XML elements. You can use schemas to place constraints on the XML data, but these constraints are not really enforced by the database (except insofar as the database is used to validate via a schema). And the ability to place constraints on XML data doesn't quite add up to the ability to the ability to ensure the same level of consistency checking offered by referential integrity in a relational database. However, there is a possible answer. This is one of the cases where using a hybrid relational/XML database proves to be very useful.

Schemas: Stereotypes, Archetypes or Prototypes?
Rick Jelliffe, O'Reilly Technical

The problem with schemas is this: sometimes we need prototypes, sometimes we need archetypes, sometimes we need stereotypes, but transitioning between them is not trivial in any schema language, which may be optimised for particular cases. Schema-as-stereotype is the classical view of a schema: something solid that is emulated. The old SGML idea of DTD as a contract between document provider and consumer is schema-as-stereotype. However, when you have data interchange between preexisting systems which, though the same domain, were not each designed with a view to interchange, the availability of data becomes the luck of the draw. In this kind of case, the official schema becomes a wish list, a way of labelling information that does fit in shared ways. Think of the large industry-specific schemas such as ACORD. Schema-as-archetype is this wish-list view of a schema. There are quite a few schemas which borrow with minor changes from other schemas: ODF's not-quite-SVG graphics and OOXML's inspired-by-SMIL animations for example—if we take the stereotype view of schemas, these are quite wrong, but if we take the archetype view, they are unsurprising. Schemas evolve... We can see that grammars are quite good as stereotypes. Namespaces are designed to help with archetypes and the namespaces-aware schema languages are helpful; however often as a practical matter architype labels (old-timers: I mean architectural forms of course) are often expressed using attribute values (see microformats) that elude the grammar-based validators. And while XSD has its type derivation mechanisms to allow evolution, the base schema is not the prototype, because it may need to be adjusted in order to cope with derived schemas. Is Schematron the answer here? I don't know, and I don't see any reason why any one schema language should necessarily be best in each of these three cases, let alone be best in transitioning between them. Schematron's phase mechanism, its open content-model foundation, and its built-in restriction semantics certainly look like being the ballpark for many cases...


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

Headlines

Sponsors