Cover Pages: XML Daily Newslink: Monday, 23 June 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

Liberty Alliance Specifications: Privacy Constraints and CARML Profile
XML Fever: Beware of Exaggerated Claims
SAML V2.0 Information Card Token Profile
Interview: David Baron on Firefox 3 and W3C Standards
Public Review Draft: User Interface Markup Language (UIML) Version 4.0
W3C Issues Last Call for XML Schema Definition Language (XSD) 1.1
Open Source WSO2 Registry 1.1 Released
Standardization as a Collective Loss of Imagination?

Liberty Alliance Specifications: Privacy Constraints and CARML Profile
Staff, Liberty Alliance Announcement

Liberty Alliance has announced the first public release of components of the Liberty Identity Governance Framework. Developed with wide cross-industry support, the Liberty Identity Governance Framework (IGF) is the industry's first programmatic and auditable open standards-based initiative designed to help organizations better govern and protect identity-related employee, customer and partner information as it flows across heterogeneous applications and networks. The IGF helps organizations meet regulatory requirements such as the European Data Protection Initiative, Gramm-Leach-Bliley Act, PCI Security Standard, and Sarbanes-Oxley by allowing enterprises to more easily determine and control how identity information, including personally identifiable information (PII), is used, stored and propagated across diverse systems, helping to ensure the information is easily auditable and not abused, compromised or misplaced. For example, with the IGF, an enterprise that may require customers to submit a social security number as part of account registration, could easily monitor which applications need to have access to social security numbers to ensure that only authorized credit verification services have direct access to this information. Two draft specifications are included in today's release: (1) CARML Specification" The CARML specification is a policy format that applications, devices, and services can use to characterize required identity data, coupled with privacy constraints governing use. It allows auditors and deployers to understand what identity information an application requires so that services can be deployed flexibly over enterprise identity architectures based on LDAP, Liberty SAML 2.0 Federation, WS-Trust, and Liberty Web Services (ID-WSF). (2) Privacy Constraints Specification: The Privacy Constraints specification provides a means of expressing commitments and obligations about identity data. It defines a small set of privacy terms, concerned with purpose, propagation, storage and display of identity data, which can be further profiled for use by industry verticals and national jurisdictions... Ongoing IGF standards development is taking place within the Liberty Alliance Technology Expert Group and OpenLiberty.org, a community driven open source project formed to facilitate the development of interoperable, secure and privacy-respecting identity-enabled applications based on Liberty Alliance specifications.

See also: Liberty Alliance references

XML Fever: Beware of Exaggerated Claims
Erik Wilde and Robert J .Glushko, XML.com

"XML Fever" was published in the July 2008 issue of the journal 'Communications of the ACM (CACM)'. "The Extensible Markup Language (XML), which just celebrated its tenth birthday, is one of the big success stories of the Web. Apart from basic Web technologies (URIs, HTTP, and HTML) and the advanced scripting driving the Web 2.0 wave, XML is by far the most successful and ubiquitous Web technology. With great power, however, comes great responsibility, so while XML's success is well earned as the first truly universal standard for structured data, it must now deal with numerous problems that have grown up around it. These are not entirely the fault of XML itself, but instead can be attributed to exaggerated claims and ideas of what XML is and what it can do... When someone first learns about it, XML may seem like the hammer in the cliche about everything looking like a nail. Those of us who teach XML, write about it, or help others become effective users of it, however, can encourage a more nuanced view of XML tools and technologies that portrays them as a set of hammers of different sizes, with a variety of grips, heads, and claws. We need to point out that not everyone needs a complete set of hammers, but information architects should know how to select the appropriate hammer for the kind of hammering they need to do. And we should always remember that pounding nails is only one of the tasks involved in design and construction. XML has succeeded beyond the wildest expectations as a convenient format for encoding information in an open and easily computable fashion. But it is just a format, and the difficult work of analysis and modeling information has not and will never go away.

See also: the full preprint version

SAML V2.0 Information Card Token Profile
Scott Cantor (ed), OASIS Working Draft

A draft version of the "SAML V2.0 Information Card Token Profile" has been submitted to the OASIS Security Services (SAML) TC. "Microsoft has defined a set of profiles for acquring and delivering security tokens, collectively referred to as 'Information Card' technology. These profiles are agnostic with respect to the format and semantics of a security token, but interoperability between issuing and relying parties cannot be achieved without additional rules governing the creation and use of the tokens exchanged. This profile describes a set of rules for identity providers and relying parties to follow when using SAML 2.0 assertions as managed information card security tokens, so that interoperability and security is achieved commensurate with other SAML authentication profiles... Identity providers and relying parties employing the Identity Selector Interoperability Profile V1.0 (ISIP - Microsoft) to request and exchange security tokens are able to use arbitrary token formats, provided there is agreement on the token's syntax and semantics, and a way to connect the token's content to the supported protocol features. This profile provides a set of requirements and guidelines for the use of SAML 2.0 assertions as security tokens that, where possible, emulates existing SAML 2.0 authentication profiles so as to limit the amount of new work that must be done by existing software to support the use of Information Cards. It also provides for the use of SAML assertions in this new context that is safe, and consistent with best practices in similar contexts. This profile does not seek to alter the required behavior of existing identity selector software, or conflict with the profiles defined by ISIP. While the SAML V2.0 specification defines an identity provider solely in terms of the SAML Authentication Request protocol, the term is generally applicable to an entity that issues authentication assertions by means of other, similar protocols. In this case, the identity provider functions as an IP/STS in the Information Card vocabulary, and issues assertions in response to 'wst:RequestSecurityToken' messages (WS-Trust). As defined by ISIP, the request contains information that provides input into the assertion creation process..."

See also: early news on ICF

Interview: David Baron on Firefox 3 and W3C Standards
Staff, W3C Questions and Answers Blog

At the news of the official release of Firefox 3 (FF3), W3C asked David Baron (Mozilla's Advisory Committee Representative at W3C) a few questions about the browser release and support for standards. First: "So, is the rumor true that Firefox 3 implements every W3C Recommendation perfectly?" Baron: "No... [As to noteworthy changes and Mozilla's priorities in CSS support]: "Some of the Firefox 3 changes I think authors will be most interested in are inline-block and inline-table, font-size-adjust, 'rgba()' and 'hsla()' colors, new values for width, min-width, and max-width, and white-space: pre-wrap. These are the ones I mentioned in that post. One of the top things that will ease cross-browser authoring is inline-block. But a larger part of the work in easing cross-browser authoring is really the large numbers of small bug fixes that have gone into this release. As far as priorities for CSS support go, we want to continue improving conformance to CSS 2.1. Fixing bugs in the details makes it more likely authors will find the same behavior in different browsers in real-world use of the specifications. We're also looking at adding a bunch of additional features over the next year. It's hard to know which features will end up in which release because we don't really know how hard they are or how long they take to implement until we try. But some of the things we're looking at or working on are downloadable fonts (both OpenType and SVG) through '@font-face', allowing some CSS properties from SVG (like clip-path, mask, and filter) to be used with other languages, new graphical properties like text shadows, border images, and box shadows, implementing CSS media queries, the remaining selectors in css3-selectors, some of the new functions in css3-values like 'calc()', and Apple's proposal for CSS transformations, and standardizing and improving the flexible box model that we use to construct the user interface of Firefox and other Mozilla-based applications. I think these align reasonably well with the priorities of the CSS working group, which is actively working on the specifications in many of these areas... We've switched version control systems, from CVS to mercurial, which is a distributed version control system. Distributed version control systems have a lot of advantages over CVS, such as much better ability to work offline and better mechanisms for collaboration...

Public Review Draft: User Interface Markup Language (UIML) Version 4.0
James Helms, Robbie Schaefer, (et al., eds), OASIS PR Draft

Members of the OASIS User Interface Markup Language (UIML) Technical Committee have released an approved Committee Draft for public review, through August 21, 2008: "User Interface Markup Language (UIML) Version 4.0." The TC was chartered to develop a specification for an abstract meta-language that can provide a canonical XML representation of any user interface (UI), where the language should be capable of specifying the requirements, design, and implementation of any UI. Specification summary: "The design objective of the UIML is to provide a vendor-neutral, canonical (or standard form) representation of any UI suitable for mapping to existing languages. We use the term canonical to refer to the fact that UIML has enough expressive power to represent any UI that can be represent by modern implementation and declarative languages. UIML provides a single format in which UIs can always be defined. UIML provides a puzzle piece to be used in conjunction with other technologies, including UI design methodologies, design languages, authoring tools, transformation algorithms, and existing languages and standards (OASIS and W3C specifications). UIML is in no way a silver bullet that replaces human decisions needed to create Uis. UIML is a structured presentation specification language: it allows to describe the user interface for an interactive system in XML. UIML is biased toward an object-oriented view and being a user interface meta-language, complementary with most other specifications (e.g., SOAP, XForms Models, XHTML, HTML, WML, VoiceXML). During the design of UIML an effort was made to allow interface descriptions in UIML to be mapped with equal efficiency to various vendor's technologies (e.g., UIML should efficiently map to both ASP .Net and to JSP to provide vendor-independence in Web Services).

See also: the announcement

W3C Issues Last Call for XML Schema Definition Language (XSD) 1.1
Sandy Gao, C. M. Sperberg-McQueen, Henry S. Thompson (eds), W3C TR

Members of the W3C Schema Working Group have published Last Call Working Drafts for "W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures" and "W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes." Public comments are invited through 12-September-2008. Part 1 specifies the XML Schema Definition Language, which offers facilities for describing the structure and constraining the contents of XML documents, including those which exploit the XML Namespace facility. The schema language, which is itself represented in an XML vocabulary and uses namespaces, substantially reconstructs and considerably extends the capabilities found in XML document type definitions (DTDs). This specification depends 'Part 2: Datatypes.' The Datatypes specification provides facilities for defining datatypes to be used in XML Schemas as well as other XML specifications. The datatype language, which is itself represented in XML, provides a superset of the capabilities found in XML document type definitions (DTDs) for specifying datatypes on elements and attributes. Michael Sperberg-McQueen notes that XSD 1.1 is "somewhat improved over XSD 1.0 in a number of ways, ranging from the very small but symbolically very significant to much larger changes. On the small but significant side: the spec has a name now (XSD) that is distinct from the generic noun phrase used to describe the subject matter of the spec (XML schemas), which should make it easier for people to talk about XML schema languages other than XSD without confusing some listeners. On the larger side: (1) XSD 1.1 supports XPath 2.0 assertions on complex and simple types. The subset of XPath 2.0 defined for assertions in earlier drafts of XSD 1.1 has been dropped; processors are expected to support all of XPath 2.0 for assertions. (There is, however, a subset defined for conditional type assignment, although here too schema authors are allowed to use, and processors are allowed to support, full XPath.) (2) 'Negative' wildcards are allowed, that is wildcards which match all names except some specified set. The excluded names can be listed explicitly, or can be 'all the elements defined in the schema' or 'all the elements present in the content model'. (3) The 'xs:redefine' element has been deprecated, and a new xs:override element has been defined which has clearer semantics and is easier to use... Some changes vis-a-vis 1.0 were already visible in earlier drafts of 1.1. The rules requiring deterministic content models have been relaxed to allow wildcards to compete with elements (although the determinism rule has not been eliminated completely, as some would prefer). XSD 1.1 supports both XML 1.0 and XML 1.1...

Open Source WSO2 Registry 1.1 Released
Staff, WSO2 Announcement

WSO2 has announced the release of the WSO2 Registry Version 1.1. WSO2 is a Open Source technology company building Open Source middleware platforms for Web services and SOA. WSO2 delivers integrated middleware stacks based on components developed at Apache, offering industry leading performance and convenience for customers. Founded in August 2005 by pioneers in Web services and Open Source, WSO2 engineers contribute heavily to many key Apache Web services projects... "The WSO2 Registry is a hub for managing data in a web-friendly and community-enabled way. It was built with enterprise metadata for SOA in mind, but really it's up to you—the Registry can hold any kind of 'stuff' including images, service descriptions, text files, office documents, and every resource you put in the Registry becomes a center for social activity. Eschewing the complexity (and WS-* focus) of specs like UDDI, our Registry uses the Atom Publishing Protocol (via Apache Abdera) to offer a standard and RESTfully simple remote interface, which can be accessed easily by custom code, feed readers, and even browsers. The Registry has been designed both to encourage 'grass-roots' community around your data and also to allow for IT-friendly governance. Some major changes from last release include performance improvements, change from auto-versioning collections to explicit checkpointing Lifecycle/Aspect support, much improved WSDL handling, validation, and WS-I validation support for transaction handling, and generic typed associations. Major features in WSO2 Registry Version 1.1 include, for example: (1) Storing and managing arbitrary resources and collections; (2) Tagging, commenting and rating; (3) Managing users and roles; (4) Authentication and authorization on all resources and actions; (5) Resource/collection versioning and rollback; (6) Advanced search capabilities—tags, users, etc; (7) Built in media type support for common types (WSDL, XSD); (8) Built in support for WSDL and Schema validation; (9) Built in support for WSI validation; (10) Dependency management—maintain relationships between dependent resources; (11) Pluggable media type handlers for handling custom media types; (12) Support for processing custom URL patterns via pluggable URL handlers; (13) Support for custom query languages via pluggable query processors; (14) Activity log and filtering support for the activity logs; (15) Atom Publishing Protocol (APP) support for reading/writing the data store remotely; (16) Subscribe to directories, comments, tags, etc. with any standard feed reader—Bloglines, Google Reader, etc..."

See also: the WSO2 Registry home page

Standardization as a Collective Loss of Imagination?
Rick Jelliffe, O'Reilly Articles

"Regularly as clockwork, every five years another group attempts to make a new standard language for typesetting. FOSI, DSSSL, XSL-FO, and ODF (plus the less grandiose scopes of CSS (styling) and OOXML (legacy).) I predict that in a decade we will see the same thing. In the past, these efforts came from the user side rather than the vendor side, and were driven by user requirements rather than vendor requirements. But requirements for standards now predominately come from questions about 'Our product X supports feature Y and therefore the standard should support it' rather than 'Our document A uses typesetting feature B therefore the standard should support it': the cart is driving the horse. There is more vendor buy-in because the new standards demand and achieve so little. In part it is understandable, as the catch-up mentality does not necessarily encourage imagination... Now the history of (SGML and) XML is the effort to key presentation cues from structural information: the benefit of marking up 'invisible' containers is that they are often not invisible. The current approach of both ODF and OOXML of allowing foreign container elements (in different syntaxes) but not providing facilities to format based on them, is the worst of all words: for QUASIWYG systems users will be loathe to do anything (well) which does not have a resulting visual/stylistic result in the on-screen draft. And (as was pioneered in pre-Adobe FrameMaker and taken up in CSS) the abstraction of frames (floating or relative, linked boundaries into which text can be flowed) also provides many hooks for making declarative properties that otherwise might require programming. The way that standards for public declarative publishing formats (whether HTML or ODF) should go, in my opinion, is by progressively asking the question, 'How can we make it easier for users to do what they want to do?' [...] We are quite lucky that countries like China are now getting fed up with the lack of imagination and responsiveness by Western developers and standards makers: it provides one of the few chinks in the protective armour by vendors that they only want change when driven by them... So the only drivers I see for this [change] is for large user-side organizations to participate and dominate all the standards bodies, to work out their checklists, and force through the changes to ODF/OOXML/CSS/HTML that are required to conform to how people make documents when their focus is on good or natural page design (usability) rather than on incrementalism and conservativism..."


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

Headlines

Sponsors