Date:
Tue, June 24, 2008 08:13:04 AMFrom:
Robin Cover
Subject:
XML Daily Newslink. Monday, 23 June 2008
XML Daily Newslink. Monday, 23 June 2008
A Cover Pages Publication http://xml.coverpages.org/
Provided by OASIS http://www.oasis-open.org
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.
http://xml.coverpages.org/LibertyIGF-PrivacyConstraintsCARML.html
See also Liberty Alliance references: http://xml.coverpages.org/libertyAlliance.html
----------------------------------------------------------------------
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.
http://www.oreillynet.com/xml/blog/2008/06/xml_fever.html
See also the full preprint version: http://dret.net/netdret/docs/wilde-cacm2008-xml-fever.html
----------------------------------------------------------------------
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..."
http://xml.coverpages.org/saml.html#CantorScott-SAML2-Infocard-v01
See also early news on ICF:
http://www.microsoft-watch.com/content/security/what_the_heck_is_information_card_foundation.html
----------------------------------------------------------------------
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...
http://www.w3.org/QA/2008/06/interview_david_baron_on_firef
See also W3C Cascading Style Sheets home page: http://www.w3.org/Style/CSS/
----------------------------------------------------------------------
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).
http://docs.oasis-open.org/uiml/v4.0/cd01/uiml-4.0-cd01.html
See also the announcement: http://lists.oasis-open.org/archives/tc-announce/200806/msg00013.html
----------------------------------------------------------------------
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...
http://www.w3.org/TR/2008/WD-xmlschema11-1-20080620/
See also Michael Sperberg-McQueen's Blog: http://people.w3.org/~cmsmcq/blog/?p=57
----------------------------------------------------------------------
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..."
http://xml.coverpages.org/WSO2-V11.html
See also the WSO2 Registry home page: http://wso2.org/projects/registry
----------------------------------------------------------------------
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..."
http://www.oreillynet.com/xml/blog/2008/06/standardization_as_a_collectiv.html
----------------------------------------------------------------------
XML Daily Newslink and Cover Pages are sponsored by:
IBM Corporation http://www.ibm.com
Oracle Corporation http://www.oracle.com
Primeton http://www.primeton.com
Sun Microsystems, Inc. http://sun.com
----------------------------------------------------------------------
XML Daily Newslink: http://xml.coverpages.org/newsletter.html
Newsletter archive: http://xml.coverpages.org/newsletterArchive.html
Newsletter subscribe: newsletter-subscribe@xml.coverpages.org
Newsletter ***: newsletter-***@xml.coverpages.org
Newsletter help: newsletter-help@xml.coverpages.org
Cover Pages: http://xml.coverpages.org/
----------------------------------------------------------------------


Back to newsletter list