How to choose a model for interoperable communication in the enterprise?
For the implementation of Web Services in the enterprise environment,
I've seen many different technologies used. Recently, in my spare moments,
I've reflected on this and have come to the conclusion that all these
technologies tend to fit one of three models (or hybrids of these models).
I would summarise these three models as: (1) Remote Procedure Calls (RPC).
A client-server based remotable pattern where a subset of an existing
system's local functions is exposed pretty much 'as-is' over the wire
to client programs. (2) Resource-oriented Create-Read-Update-Delete
(CRUD). A client-server based resource-oriented pattern where the
server-side provides a representation of a set of resources (often
hierarchical) and exposes Create, Read, Update and Delete capabilities
for these resources to client programs. (3) Messaging (e.g., as commonly
seen with Message Oriented Middleware and B2B). Messages or documents are
passed asynchronously between peer systems in either, but not always both,
directions. Sometimes its hard to distinguish between these models and
where the boundaries lie. In fact, I don't think there are boundaries,
only grey areas and all three models lie in the same spectrum. In the
Web Services world, we may typically implement these three models using
one of the following three approaches: (1') Remote Procedure Calls: SOAP
using a synchronous RPC programming approach and, typically, generated
'skeletons/stubs' and some sort of Object-to-XML marshalling technology.
(2') Resource-oriented Create-Read-Update-Delete: REST or 'RESTful Web
Services' or ROA, re-using World-Wide-Web based approaches and standards
like HTTP and URIs. (3') Messaging: SOAP using an asynchronous
Message/Document passing approach where invariably the documents are
defined by schemas and, often, the use of message-level (rather than
transport-level) security elements is required... When faced with the
REST zealot or the WS-* zealot, we probably need to bear this spectrum
in mind. For the Web Services paradigm, there is not a 'one-size fits all'
and specific requirements for a given situation should dictate which
position in this spectrum best lends itself to satisfying the requirements.
Also, the overlap between the models may be greater [than shown in the
diagram]. For example, some would argue that REST can happily and more
appropriately be used to fulfil what would otherwise be RPC oriented
problems, in addition to solving Resource-oriented CRUD style problems.
Wednesday, February 27, 2008
Holder-of-Key Web Browser SSO Profile
"As part of my work for the National Institute of Informatics and the
UPKI initiative, I've been working on a modified Web Browser SSO profile
for SAML 2.0 that uses holder-of-key confirmation for the client rather
than bearer authentication. The keys for this confirmation are supplied
through TLS using client certificates. This results in a more secure
sign-on process and, particularly, a more secure resulting session at
the SP. There is no need for the SP to do PKI validation or know
anything about the client certificate itself. The specification
supplies an alternative to "Profiles for the OASIS Security Assertion
Markup Language (SAML) V2.0." Excerpt: "The profile allows for transport
and validation of holder-of-key assertions by standard HTTP user agents
with no modification of client software and maximum compatibility with
existing deployments. Most of the flows are as in standard Web Browser
SSO, but an x.509 certificate presented by the user agent supplies a
valid keypair through client TLS authentication for HTTP transactions.
Cryptographic data resulting from TLS authentication is used for
holder-of-key validation of a SAML assertion. This strengthens the
assurance of the resulting authentication context and protects against
credential theft, giving the service provider fresh authentication and
attribute information without requiring it to perform successful
validation of the certificate... A principal uses an HTTP user agent
to either access a web-based resource at a service provider or access
an identity provider such that the service provider and desired resource
are understood or implicit. In either case, the user agent needs to
acquire a SAML assertion from the identity provider. The user agent
makes a request to the identity provider using client TLS authentication.
The X.509 certificate supplied in this transaction is used primarily to
supply a public key that is associated with the principal. The identity
provider authenticates the principal by way of this TLS authentication
or any other method of its choice. The identity provider then produces
a response containing at least an assertion with holder-of-key subject
confirmation and an authentication statement for the user agent to
transport to the service provider. This assertion is presented by the
user agent to the service provider over client TLS authentication to
prove possession of the private key matching the holder-of-key
confirmation in the assertion. The service provider should rely on no
information from the certificate beyond the key; instead, it consumes
the assertion to create a security context. The TLS key may then be
used to persist the security context rather than a cookie or other
application-layer session. To implement this scenario, a profile of
the SAML Authentication Request protocol is used in conjunction with
the HTTP Redirect, HTTP POST and HTTP Artifact bindings. It is assumed
that the user is using an HTTP user agent capable of presenting client
certificates during TLS session establishment, such as a standard web
browser...
UPKI initiative, I've been working on a modified Web Browser SSO profile
for SAML 2.0 that uses holder-of-key confirmation for the client rather
than bearer authentication. The keys for this confirmation are supplied
through TLS using client certificates. This results in a more secure
sign-on process and, particularly, a more secure resulting session at
the SP. There is no need for the SP to do PKI validation or know
anything about the client certificate itself. The specification
supplies an alternative to "Profiles for the OASIS Security Assertion
Markup Language (SAML) V2.0." Excerpt: "The profile allows for transport
and validation of holder-of-key assertions by standard HTTP user agents
with no modification of client software and maximum compatibility with
existing deployments. Most of the flows are as in standard Web Browser
SSO, but an x.509 certificate presented by the user agent supplies a
valid keypair through client TLS authentication for HTTP transactions.
Cryptographic data resulting from TLS authentication is used for
holder-of-key validation of a SAML assertion. This strengthens the
assurance of the resulting authentication context and protects against
credential theft, giving the service provider fresh authentication and
attribute information without requiring it to perform successful
validation of the certificate... A principal uses an HTTP user agent
to either access a web-based resource at a service provider or access
an identity provider such that the service provider and desired resource
are understood or implicit. In either case, the user agent needs to
acquire a SAML assertion from the identity provider. The user agent
makes a request to the identity provider using client TLS authentication.
The X.509 certificate supplied in this transaction is used primarily to
supply a public key that is associated with the principal. The identity
provider authenticates the principal by way of this TLS authentication
or any other method of its choice. The identity provider then produces
a response containing at least an assertion with holder-of-key subject
confirmation and an authentication statement for the user agent to
transport to the service provider. This assertion is presented by the
user agent to the service provider over client TLS authentication to
prove possession of the private key matching the holder-of-key
confirmation in the assertion. The service provider should rely on no
information from the certificate beyond the key; instead, it consumes
the assertion to create a security context. The TLS key may then be
used to persist the security context rather than a cookie or other
application-layer session. To implement this scenario, a profile of
the SAML Authentication Request protocol is used in conjunction with
the HTTP Redirect, HTTP POST and HTTP Artifact bindings. It is assumed
that the user is using an HTTP user agent capable of presenting client
certificates during TLS session establishment, such as a standard web
browser...
Liberty Alliance Announces Health Identity Management SIG
Liberty Alliance, the global identity consortium working to build a
more trusted internet for consumers, governments and businesses worldwide,
has announced the launch of a global public forum formed to develop an
interoperable, secure and privacy-respecting information exchange system
for the healthcare sector. The Liberty Alliance Health Identity Management
Special Interest Group (HIM SIG) is leveraging the Liberty Alliance model
of addressing the technology, business and privacy aspects of digital
identity management to meet the unique identity management and regulatory
challenges facing the international healthcare industry today. The
Health Identity Management SIG offers members an opportunity to join
with other Liberty Alliance Members (regardless of membership level)
to recommend standards to enable an internationally interoperable health
care identity management and information exchange system. This may
includes standard directory (LDAP) models, health care roles,
implementation guides, and similar recommendations. The SIG will review
existing standards, and recommend new standards for an interoperable
health care identity management system using Security Assertion Markup
Language (SAML) and Liberty Specifications. Co-chaired by John Fraser,
CEO, MEDNET USA and Pete Palmer, Security and Cryptography Architect,
Wells Fargo, the HIM SIG currently includes over 30 members from around
the world representing the education, government, healthcare and technology
sectors. Members are working to address how the healthcare industry will
deliver secure identity management solutions that meet global regulatory
mandates and ensure patient privacy. The public group is working closely
with the Liberty Identity Assurance Expert Group to ensure requirements
for standardized and certified identity assurance levels in the
healthcare sector meet criteria established in the policy-based Liberty
Identity Assurance Framework.
more trusted internet for consumers, governments and businesses worldwide,
has announced the launch of a global public forum formed to develop an
interoperable, secure and privacy-respecting information exchange system
for the healthcare sector. The Liberty Alliance Health Identity Management
Special Interest Group (HIM SIG) is leveraging the Liberty Alliance model
of addressing the technology, business and privacy aspects of digital
identity management to meet the unique identity management and regulatory
challenges facing the international healthcare industry today. The
Health Identity Management SIG offers members an opportunity to join
with other Liberty Alliance Members (regardless of membership level)
to recommend standards to enable an internationally interoperable health
care identity management and information exchange system. This may
includes standard directory (LDAP) models, health care roles,
implementation guides, and similar recommendations. The SIG will review
existing standards, and recommend new standards for an interoperable
health care identity management system using Security Assertion Markup
Language (SAML) and Liberty Specifications. Co-chaired by John Fraser,
CEO, MEDNET USA and Pete Palmer, Security and Cryptography Architect,
Wells Fargo, the HIM SIG currently includes over 30 members from around
the world representing the education, government, healthcare and technology
sectors. Members are working to address how the healthcare industry will
deliver secure identity management solutions that meet global regulatory
mandates and ensure patient privacy. The public group is working closely
with the Liberty Identity Assurance Expert Group to ensure requirements
for standardized and certified identity assurance levels in the
healthcare sector meet criteria established in the policy-based Liberty
Identity Assurance Framework.
PRESTO: A WWW Information Architecture for Legislation and PublicPRESTO: A WWW Information Architecture for Legislation and Public
PRESTO (P - Public, Permanent URLs; REST - Representation, State
Transfer; O - Object-oriented) is not something new: its basic ideas are
presupposed in a lot of people's thinking about the web, and many people
have given names to various parts. The elevator pitch for PRESTO is this:
"All documents, views and metadata at all significant levels of
granularity and composition should be available in the best formats
practical from their own permanent hierarchical URIs." I would see PRESTO
as the kind of methodology that a government could adopt as a
whole-of-government approach, in particular for public documents and
of these in particular for legislation and regulations. The problem is
not 'what is the optimal format for our documents?' The question is 'How
can link to the important grains of information in a robust,
technology-neutral way that only needs today's COTS tools?' The format
wars, in this area, are asking exactly the wrong question: they focus
us on the details of format A rather than format B, when we need to be
able to name and link to information regardless of its format:
supra-notational data addressing. If you are wanting to build a large
information system for the kinds of documents, and you want to be truly
vendor neutral (which is not the same thing as saying that preferences
and delivery-capabilities will not still play their part), and you want
to encourage incremental, decentralized ad hoc and planned developments
in particular mash-ups, then you need Permanent URLs (to prevent link rot),
you need REST (for scale etc) and you need object-oriented (in the sense
of bundling the methods for an object with the object itself, rather than
having separate verb-based web services which implement a functional
programming approach: OO here also including introspection so that when
you have a resource you can query it to find the various operations
available). A rule of thumb for a document system that conformed to this
PRESTO approach would be that none of the URLs use '#' (which indicates
that you are groping for information inside a system-dependent level of
granularity rather than being system-neutral) or '?' (which indicates that
you are not treating every object you can think about as a resource in
its own right that may itself have metadata and children.)
Transfer; O - Object-oriented) is not something new: its basic ideas are
presupposed in a lot of people's thinking about the web, and many people
have given names to various parts. The elevator pitch for PRESTO is this:
"All documents, views and metadata at all significant levels of
granularity and composition should be available in the best formats
practical from their own permanent hierarchical URIs." I would see PRESTO
as the kind of methodology that a government could adopt as a
whole-of-government approach, in particular for public documents and
of these in particular for legislation and regulations. The problem is
not 'what is the optimal format for our documents?' The question is 'How
can link to the important grains of information in a robust,
technology-neutral way that only needs today's COTS tools?' The format
wars, in this area, are asking exactly the wrong question: they focus
us on the details of format A rather than format B, when we need to be
able to name and link to information regardless of its format:
supra-notational data addressing. If you are wanting to build a large
information system for the kinds of documents, and you want to be truly
vendor neutral (which is not the same thing as saying that preferences
and delivery-capabilities will not still play their part), and you want
to encourage incremental, decentralized ad hoc and planned developments
in particular mash-ups, then you need Permanent URLs (to prevent link rot),
you need REST (for scale etc) and you need object-oriented (in the sense
of bundling the methods for an object with the object itself, rather than
having separate verb-based web services which implement a functional
programming approach: OO here also including introspection so that when
you have a resource you can query it to find the various operations
available). A rule of thumb for a document system that conformed to this
PRESTO approach would be that none of the URLs use '#' (which indicates
that you are groping for information inside a system-dependent level of
granularity rather than being system-neutral) or '?' (which indicates that
you are not treating every object you can think about as a resource in
its own right that may itself have metadata and children.)
Why Liberty's Identity Governance Framework is So Important
In late 2006, several companies got together and created the Identity
Governance Framework (IGF), an initiative of the Liberty alliance.
The purpose of the IGF is to provide an open architecture that
addresses governance of identity related information. This architecture
is meant to bridge the gap between regulatory requirements and the
lower-level protocols and architecture. How can the inherent risks
associated with the creation, copying, maintenance and use of identity
data be mitigated? Who has access to what data for which purpose, and
under what conditions? Ideally, policies on data usage are created by
sources (attribute authorities) and consumers (attribute authorities)
of identity data. These policies can then then be used for the
implementation and auditing of governance. In other words: if you
know what the rules are, express them in a policy, and make sure your
policy is watertight when the next audit comes. Exactly this is what
the IGF attempts to create: a standardised mechanism for expression
and implementation of these policies. The IGF is working on several
standards and components to make this happen. One of them is the CARML
(Client Attribute Request Markup Language) protocol. It defines
application identity requirements, in other words what type of identity
information an application needs, and what that application will do
with that information. On the other side of the spectrum there is AAPML
('Attribute Authority Policy Markup Language') that describes the
constraints on the use of the provided identity information -- under
what conditions specific pieces of identity data is made available to
applications, and how this data may be used, and possibly modified.
For example: what part of the users data can be modified by the users
directly at a self-service portal? Or: under which condition may a
marketing application use a users data, and what type of explicit consent
needs to be given by the user? AAPML is proposed as a profile of XACML,
so that AAPML policies can be consumed directly by a policy enforcement
point (PEP) to enforce access over the requests for identity data...
CARML and AAPML bridge a very important gap that is not addressed
anywhere else: not how to request and receive attributes, but to
express the need and purpose of identity data, and on the other side
the allowed use and conditions for its consumption. IGF's framework
conceptually fits seamlessly into architectures harnessing today's
frameworks and picks up where CardSpace, Higgins, Bandit and WS-Trust,
leave off.
Governance Framework (IGF), an initiative of the Liberty alliance.
The purpose of the IGF is to provide an open architecture that
addresses governance of identity related information. This architecture
is meant to bridge the gap between regulatory requirements and the
lower-level protocols and architecture. How can the inherent risks
associated with the creation, copying, maintenance and use of identity
data be mitigated? Who has access to what data for which purpose, and
under what conditions? Ideally, policies on data usage are created by
sources (attribute authorities) and consumers (attribute authorities)
of identity data. These policies can then then be used for the
implementation and auditing of governance. In other words: if you
know what the rules are, express them in a policy, and make sure your
policy is watertight when the next audit comes. Exactly this is what
the IGF attempts to create: a standardised mechanism for expression
and implementation of these policies. The IGF is working on several
standards and components to make this happen. One of them is the CARML
(Client Attribute Request Markup Language) protocol. It defines
application identity requirements, in other words what type of identity
information an application needs, and what that application will do
with that information. On the other side of the spectrum there is AAPML
('Attribute Authority Policy Markup Language') that describes the
constraints on the use of the provided identity information -- under
what conditions specific pieces of identity data is made available to
applications, and how this data may be used, and possibly modified.
For example: what part of the users data can be modified by the users
directly at a self-service portal? Or: under which condition may a
marketing application use a users data, and what type of explicit consent
needs to be given by the user? AAPML is proposed as a profile of XACML,
so that AAPML policies can be consumed directly by a policy enforcement
point (PEP) to enforce access over the requests for identity data...
CARML and AAPML bridge a very important gap that is not addressed
anywhere else: not how to request and receive attributes, but to
express the need and purpose of identity data, and on the other side
the allowed use and conditions for its consumption. IGF's framework
conceptually fits seamlessly into architectures harnessing today's
frameworks and picks up where CardSpace, Higgins, Bandit and WS-Trust,
leave off.
Beta Release: ID-WSF 2.0 Web Services Client Library (ClientLib)
Asa Hardcastle, OpenLiberty Technical Lead, has announced the beta
release of the ID-WSF 2.0 ClientLib application. openLiberty.org was
established to provide easy access to tools and information to jump
start the development of more secure and privacy-respecting
identity-based applications based on Liberty Alliance standards. The
first project at openLiberty.org is the ID-WSF WSC Client Library
("ClientLib") that will help you more easily build and deploy a wide
range of new relying party (identity-consuming) applications. The
ClientLib uses OpenSAML's Java XML Tooling, SOAP, and SAML2 Libraries.
As announced: "As of February 25th 2008 the ClientLib is officially
released as BETA code. Over the next few months we'll be writing more
code and doing some interoperability testing. The ClientLib includes
support for ID-WSF Authentication Service (PLAIN and CRAM-MD5),
Discovery Service, a non-standard Profile Service, and Directory Access
Protocol Service (ID-DAP). Both signed and unsigned messaging is
supported. The Data Services Template (DST 2.1) is mostly complete.
The DST 2.1 reference implementation is mostly complete. People Service
is partially complete." From Asa's blog entry: "This release marks
excellent progress, but there is still a lot of work to do. The beta
is not bug free nor is it thoroughly tested. It is ready for other
people to sink their teeth into and give feedback, make requests, or
write some code. For development purposes we are currently testing
against two ID-WSF WSPs and have access to a third (HP Select Federation)
which we hope to have working with the library before Version 1 release
planned later this year."
release of the ID-WSF 2.0 ClientLib application. openLiberty.org was
established to provide easy access to tools and information to jump
start the development of more secure and privacy-respecting
identity-based applications based on Liberty Alliance standards. The
first project at openLiberty.org is the ID-WSF WSC Client Library
("ClientLib") that will help you more easily build and deploy a wide
range of new relying party (identity-consuming) applications. The
ClientLib uses OpenSAML's Java XML Tooling, SOAP, and SAML2 Libraries.
As announced: "As of February 25th 2008 the ClientLib is officially
released as BETA code. Over the next few months we'll be writing more
code and doing some interoperability testing. The ClientLib includes
support for ID-WSF Authentication Service (PLAIN and CRAM-MD5),
Discovery Service, a non-standard Profile Service, and Directory Access
Protocol Service (ID-DAP). Both signed and unsigned messaging is
supported. The Data Services Template (DST 2.1) is mostly complete.
The DST 2.1 reference implementation is mostly complete. People Service
is partially complete." From Asa's blog entry: "This release marks
excellent progress, but there is still a lot of work to do. The beta
is not bug free nor is it thoroughly tested. It is ready for other
people to sink their teeth into and give feedback, make requests, or
write some code. For development purposes we are currently testing
against two ID-WSF WSPs and have access to a third (HP Select Federation)
which we hope to have working with the library before Version 1 release
planned later this year."
New Book: Understanding Windows CardSpace
"There is a really wonderful new book out on digital identity and
Information Cards called "Understanding Windows CardSpace". Written
by Vittorio Bertocci, Garrett Serack and Caleb Baker, all of whom were
part of the original CardSpace project, the book is deeply grounded in
the theory and technology that came out of it... The presentation begins
with a problem statement: 'The Advent of Profitable Digital Crime'.
There is a systematic introduction to the full panoply of attack vectors
we need to withstand, and the book convincingly explains why we need an
in-depth solution, not another band-aid leading to some new vulnerability.
For those unskilled in the art, there is an introduction to relevant
cryptographic concepts, and an explanation of how both certificates and
HTTPS work. These will be helpful to many who would otherwise find parts
of the book out of reach. Next comes an intelligent discussion of the
Laws of Identity, the multi-centered world and the identity metasystem.
The book is laid out to include clever sidebars and commentaries, and
becomes progressively more McLuhanesque. On to SOAP and Web Services
protocols -- even an introduction to SAML and WS-Trust, always with
plenty of diagrams and explanations of the threats. Then we are introduced
to the concept of an identity selector and the model of user-centric
interaction. Part two deals specifically with CardSpace, starting with
walk-throughs, and leading to implementation. This includes 'Guidance for
a Relying Party', an in-depth look at the features of CardSpace, and a
discussion of using CardSpace in the browser. The authors move on to
Using CardSpace for Federation, and explore how CardSpace works with
the Windows Communication Foundation. Even here, we're brought back to
the issues involved in relying on an Identity Provider, and a discussion
of potential business models for various metasystem actors..."
Information Cards called "Understanding Windows CardSpace". Written
by Vittorio Bertocci, Garrett Serack and Caleb Baker, all of whom were
part of the original CardSpace project, the book is deeply grounded in
the theory and technology that came out of it... The presentation begins
with a problem statement: 'The Advent of Profitable Digital Crime'.
There is a systematic introduction to the full panoply of attack vectors
we need to withstand, and the book convincingly explains why we need an
in-depth solution, not another band-aid leading to some new vulnerability.
For those unskilled in the art, there is an introduction to relevant
cryptographic concepts, and an explanation of how both certificates and
HTTPS work. These will be helpful to many who would otherwise find parts
of the book out of reach. Next comes an intelligent discussion of the
Laws of Identity, the multi-centered world and the identity metasystem.
The book is laid out to include clever sidebars and commentaries, and
becomes progressively more McLuhanesque. On to SOAP and Web Services
protocols -- even an introduction to SAML and WS-Trust, always with
plenty of diagrams and explanations of the threats. Then we are introduced
to the concept of an identity selector and the model of user-centric
interaction. Part two deals specifically with CardSpace, starting with
walk-throughs, and leading to implementation. This includes 'Guidance for
a Relying Party', an in-depth look at the features of CardSpace, and a
discussion of using CardSpace in the browser. The authors move on to
Using CardSpace for Federation, and explore how CardSpace works with
the Windows Communication Foundation. Even here, we're brought back to
the issues involved in relying on an Identity Provider, and a discussion
of potential business models for various metasystem actors..."
W3C Offices Program Celebrates Ten Years of International Outreach
W3C announced that representatives from W3C Offices -- regional branches
that promote W3C and interact with participants in local languages --
now celebrate ten years of the Offices program. Offices currently
represent seventeen (17) regions around the globe, helping to organize
meetings, recruit Members, translate materials, and find creative ways
to encourage international participation in W3C work. Offices staff
gather for a face-to-face meeting in Sophia-Antipolis France to review
ten years of experience and to forge improvements to the program. At
this occasion, W3C thanks the Offices staff past and present for all
of their work. W3C Offices are located in Australia, Brazil, Benelux,
China, Finland, Germany & Austria, Greece, Hungary, India, Israel,
Italy, Korea, Morocco, Southern Africa, Spain, Sweden, United Kingdom
and Ireland
that promote W3C and interact with participants in local languages --
now celebrate ten years of the Offices program. Offices currently
represent seventeen (17) regions around the globe, helping to organize
meetings, recruit Members, translate materials, and find creative ways
to encourage international participation in W3C work. Offices staff
gather for a face-to-face meeting in Sophia-Antipolis France to review
ten years of experience and to forge improvements to the program. At
this occasion, W3C thanks the Offices staff past and present for all
of their work. W3C Offices are located in Australia, Brazil, Benelux,
China, Finland, Germany & Austria, Greece, Hungary, India, Israel,
Italy, Korea, Morocco, Southern Africa, Spain, Sweden, United Kingdom
and Ireland
SOA Spending Up Despite Unclear Benefits
The number of companies investing in service-oriented architecture (SOA)
has doubled over the past year in every part of the world, with a
typical annual spend of nearly $1.4 million, according to a new research
report from the analyst firm AMR Research that surveyed 405 companies in
the U.S., Germany, and China. Now the bad news: "Hundreds of millions of
dollars will be invested pursuing these markets in 2008, much of it
wasted," said AMR analyst Ian Finley. The AMR survey found that most
companies don't really know why they are investing in SOA, which Finley
said makes long-term commitment iffy. Often, there are multiple reasons
cited within any organization, letting SOA appear as a buzzword
justification for unrelated individual priorities. "People more easily
rally around a thing rather than five things... that lack of a rallying
purpose for SOA calls its momentum into question." Finley is concerned
that SOA may not get picked up much beyond the early adopters -- mainly
financial services, telecommunications, and government organizations
that are more often than not predisposed to the value of architecture
and thus more willing to pursue SOA for less-quantifiable benefits --
unless a coherent set of benefits is made clear. Another danger seen
from the SOA survey is that the main benefit that the vendors sell around
SOA (code reuse) is not the real benefit that early SOA adopters have
gotten. Often the code from project A is irrelevant to project B, he
noted. That focus on reuse can cause organizations to dismiss SOA's
benefits because they're looking at the wrong metric.
has doubled over the past year in every part of the world, with a
typical annual spend of nearly $1.4 million, according to a new research
report from the analyst firm AMR Research that surveyed 405 companies in
the U.S., Germany, and China. Now the bad news: "Hundreds of millions of
dollars will be invested pursuing these markets in 2008, much of it
wasted," said AMR analyst Ian Finley. The AMR survey found that most
companies don't really know why they are investing in SOA, which Finley
said makes long-term commitment iffy. Often, there are multiple reasons
cited within any organization, letting SOA appear as a buzzword
justification for unrelated individual priorities. "People more easily
rally around a thing rather than five things... that lack of a rallying
purpose for SOA calls its momentum into question." Finley is concerned
that SOA may not get picked up much beyond the early adopters -- mainly
financial services, telecommunications, and government organizations
that are more often than not predisposed to the value of architecture
and thus more willing to pursue SOA for less-quantifiable benefits --
unless a coherent set of benefits is made clear. Another danger seen
from the SOA survey is that the main benefit that the vendors sell around
SOA (code reuse) is not the real benefit that early SOA adopters have
gotten. Often the code from project A is irrelevant to project B, he
noted. That focus on reuse can cause organizations to dismiss SOA's
benefits because they're looking at the wrong metric.
IPTC Announces NewsML-G2 and EventsML-G2 as G2-Standards
Misha Wolf (Reuters) posted an IPTC announcement about the launch of
NewsML-G2 and EventsML-G2 as the first parts of a new framework of
XML-based news exchange formats from the International Press
Telecommunications Council (IPTC). NewsML-G2 defines a string-derived
datatype called QCode (Qualified Code), which looks like this:
"CodingSchemeAlias:Code." The CodingSchemeAlias maps to an IRI
representing the CodingScheme. The IRI obtained by appending the Code
to this IRI represents the Code. The Code can contain (and start with)
most characters. The main exception is white space, and the Code can
be entirely numeric. QCodes are used as attribute values. Such
attributes accept QCodes only, so there is no conflict with IRIs/URIs.
The next steps include the creation of an OWL representation of the
NewsML-G2 Schema and Semantics, the translation into SKOS of NewsML-G2
KnowledgeItems, and the updating of our GRDDL transform to reflect the
released version of NewsML-G2. Acording to the announcement: "NewsML-G2
allows the bundling of multiple news items -- articles, photos, videos
or whatever -- and a detailed description of their content and how the
items relate to each other. Whether populating a web site with complex
news packages or building bundles of news items for resale or archiving,
NewsML-G2 provides an easy way to package and exchange news... The
G2-Standards also fit into the Semantic Web initiatives of the World
Wide Web Consortium, enriching content so that computers can more easily
search the huge universe of news. The goal is to better help news
agencies manage and distribute their massive libraries of current and
archived news content, and to help customer search engines find content
quickly and accurately. G2-Standards can be easily combined with IPTC's
groundbreaking NewsCodes, which provide a rich suite of standard terms
for describing news, to give news agencies amazing flexibility in how
news can be bundled for downstream users. With widely available digital
news archives now dating back to 1850 or earlier, news agencies,
librarians and archivists have a special interest in the rapid searching
and retrieval of news, which NewsCodes can accelerate to help drive
revenue growth." IPTC is a consortium of the world's major news
agencies, news publishers and news industry vendors. It develops and
maintains technical standards for improved news exchange that are used
by virtually every major news organization in the world.
NewsML-G2 and EventsML-G2 as the first parts of a new framework of
XML-based news exchange formats from the International Press
Telecommunications Council (IPTC). NewsML-G2 defines a string-derived
datatype called QCode (Qualified Code), which looks like this:
"CodingSchemeAlias:Code." The CodingSchemeAlias maps to an IRI
representing the CodingScheme. The IRI obtained by appending the Code
to this IRI represents the Code. The Code can contain (and start with)
most characters. The main exception is white space, and the Code can
be entirely numeric. QCodes are used as attribute values. Such
attributes accept QCodes only, so there is no conflict with IRIs/URIs.
The next steps include the creation of an OWL representation of the
NewsML-G2 Schema and Semantics, the translation into SKOS of NewsML-G2
KnowledgeItems, and the updating of our GRDDL transform to reflect the
released version of NewsML-G2. Acording to the announcement: "NewsML-G2
allows the bundling of multiple news items -- articles, photos, videos
or whatever -- and a detailed description of their content and how the
items relate to each other. Whether populating a web site with complex
news packages or building bundles of news items for resale or archiving,
NewsML-G2 provides an easy way to package and exchange news... The
G2-Standards also fit into the Semantic Web initiatives of the World
Wide Web Consortium, enriching content so that computers can more easily
search the huge universe of news. The goal is to better help news
agencies manage and distribute their massive libraries of current and
archived news content, and to help customer search engines find content
quickly and accurately. G2-Standards can be easily combined with IPTC's
groundbreaking NewsCodes, which provide a rich suite of standard terms
for describing news, to give news agencies amazing flexibility in how
news can be bundled for downstream users. With widely available digital
news archives now dating back to 1850 or earlier, news agencies,
librarians and archivists have a special interest in the rapid searching
and retrieval of news, which NewsCodes can accelerate to help drive
revenue growth." IPTC is a consortium of the world's major news
agencies, news publishers and news industry vendors. It develops and
maintains technical standards for improved news exchange that are used
by virtually every major news organization in the world.
Sunday, February 24, 2008
vCard Extensions to WebDAV (CardDAV)
Members of the IETF vCard and CardDAV (VCARDDAV) Working Group have
released an updated version of the specification "vCard Extensions to
WebDAV (CardDAV)." This IETF WG was chartered to produce: (1) A revision
of the vCard specification (RFC 2426) at proposed standard status; this
revision will include other vCard standardized extensions (RFC 2739,
4770) and extensions assisting synchronization technologies -- for
example, a per-entry UUID or per-attribute sequence number; other
extensions shall be considered either in the base specification or in
additional documents; (2) An address book access protocol leveraging
the vCard data format, for which the 'draft-daboo-carddav' I-D is the
starting point; (3) An XML schema which is semantically identical to
vCard in all ways and can be mechanically translated to and from vCard
format without loss of data. While vCard has deployed successfully and
will remain the preferred interchange format, a standard XML schema
which preserves vCard semantics might make vCard data more accessible
to XML-centric technologies such as AJAX and XSLT. Such a standard format
would be preferable to multiple proprietary XML schemas, particularly if
vCard semantics were lost by some of them and a lossy gateway problem
resulted. The draft "vCard Extensions to WebDAV (CardDAV)" defines
extensions to the Web Distributed Authoring and Versioning (WebDAV)
protocol to specify a standard way of accessing, managing, and sharing
contact information based on the vCard format. Address books containing
contact information are a key component of personal information management
tools, such as email, calendaring and scheduling, and instant messaging
clients. To date several protocols have been used for remote access to
contact data, including Lightweight Directory Access Protocol (LDAP),
Internet Message Support Protocol (IMSP) and Application Configuration
Access Protocol (ACAP - RFC 2244), together with SyncML used for
synchronization of such data. Each has key disadvantages... The proposed
CardDAV address book is modeled as a WebDAV collection with a well
defined structure; each of these address book collections contain a
number of resources representing address objects as their direct child
resources. Each resource representing an address object is called an
"address object resource". Each address object resource and each address
book collection can be individually locked and have individual WebDAV
properties. Definitions of XML elements in this document use XML element
type declarations (as found in XML Document Type Declarations), described
in Section 3.2 of the XML 1.0 Recommendation.
released an updated version of the specification "vCard Extensions to
WebDAV (CardDAV)." This IETF WG was chartered to produce: (1) A revision
of the vCard specification (RFC 2426) at proposed standard status; this
revision will include other vCard standardized extensions (RFC 2739,
4770) and extensions assisting synchronization technologies -- for
example, a per-entry UUID or per-attribute sequence number; other
extensions shall be considered either in the base specification or in
additional documents; (2) An address book access protocol leveraging
the vCard data format, for which the 'draft-daboo-carddav' I-D is the
starting point; (3) An XML schema which is semantically identical to
vCard in all ways and can be mechanically translated to and from vCard
format without loss of data. While vCard has deployed successfully and
will remain the preferred interchange format, a standard XML schema
which preserves vCard semantics might make vCard data more accessible
to XML-centric technologies such as AJAX and XSLT. Such a standard format
would be preferable to multiple proprietary XML schemas, particularly if
vCard semantics were lost by some of them and a lossy gateway problem
resulted. The draft "vCard Extensions to WebDAV (CardDAV)" defines
extensions to the Web Distributed Authoring and Versioning (WebDAV)
protocol to specify a standard way of accessing, managing, and sharing
contact information based on the vCard format. Address books containing
contact information are a key component of personal information management
tools, such as email, calendaring and scheduling, and instant messaging
clients. To date several protocols have been used for remote access to
contact data, including Lightweight Directory Access Protocol (LDAP),
Internet Message Support Protocol (IMSP) and Application Configuration
Access Protocol (ACAP - RFC 2244), together with SyncML used for
synchronization of such data. Each has key disadvantages... The proposed
CardDAV address book is modeled as a WebDAV collection with a well
defined structure; each of these address book collections contain a
number of resources representing address objects as their direct child
resources. Each resource representing an address object is called an
"address object resource". Each address object resource and each address
book collection can be individually locked and have individual WebDAV
properties. Definitions of XML elements in this document use XML element
type declarations (as found in XML Document Type Declarations), described
in Section 3.2 of the XML 1.0 Recommendation.
Last Call Working Draft for RDFa in XHTML: Syntax and Processing
Members of W3C's Semantic Web Deployment Working Group and the XHTML 2
Working Group have published a Last Call Working Draft for the
specification "RDFa in XHTML: Syntax and Processing A collection of
attributes and processing rules for extending XHTML to support RDF."
RDFa is a specification for attributes to be used with languages such
as HTML and XHTML to express structured data. The rendered, hypertext
data of XHTML is reused by the RDFa markup, so that publishers don't
need to repeat significant data in the document content. This document
only specifies the use of the RDFa attributes with XHTML. The underlying
abstract representation is RDF, which lets publishers build their own
vocabulary, extend others, and evolve their vocabulary with maximal
interoperability over time. The expressed structure is closely tied to
the data, so that rendered data can be copied and pasted along with its
relevant structure. The rules for interpreting the data are generic, so
that there is no need for different rules for different formats; this
allows authors and publishers of data to define their own formats without
having to update software, register formats via a central authority, or
worry that two formats may interfere with each other. RDFa shares some
use cases with microformats. Whereas microformats specify both a syntax
for embedding structured data into HTML documents and a vocabulary of
specific terms for each microformat, RDFa specifies only a syntax and
relies on independent specification of terms (often called vocabularies
or taxonomies) by others. RDFa allows terms from multiple independently
developed vocabularies to be freely intermixed and is designed such that
the language can be parsed without knowledge of the specific term
vocabulary being used. Motivation: RDF/XML (Syntax) provides sufficient
flexibility to represent all of the abstract concepts in RDF. However,
it presents a number of challenges; first it is difficult or impossible
to validate documents that contain RDF/XML using XML Schemas or DTDs,
which therefore makes it difficult to import RDF/XML into other markup
languages. Whilst newer schema languages such as RELAX NG do provide a
way to validate documents that contain arbitrary RDF/XML, it will be a
while before they gain wide support. Second, even if one could add RDF/XML
directly into an XML dialect like XHTML, there would be significant data
duplication between the rendered data and the RDF/XML structured data.
It would be far better to add RDF to a document without repeating the
document's existing data. One motivation for RDFa has been to devise a
means by which documents can be augmented with metadata in a general
rather than hard-wired manner. This has been achieved by creating a
fixed set of attributes and parsing rules, but allowing those attributes
to contain properties from any of a number of the growing range of
available RDF vocabularies. The values of those properties are in most
cases the information that is already in an author's XHTML document.
Working Group have published a Last Call Working Draft for the
specification "RDFa in XHTML: Syntax and Processing A collection of
attributes and processing rules for extending XHTML to support RDF."
RDFa is a specification for attributes to be used with languages such
as HTML and XHTML to express structured data. The rendered, hypertext
data of XHTML is reused by the RDFa markup, so that publishers don't
need to repeat significant data in the document content. This document
only specifies the use of the RDFa attributes with XHTML. The underlying
abstract representation is RDF, which lets publishers build their own
vocabulary, extend others, and evolve their vocabulary with maximal
interoperability over time. The expressed structure is closely tied to
the data, so that rendered data can be copied and pasted along with its
relevant structure. The rules for interpreting the data are generic, so
that there is no need for different rules for different formats; this
allows authors and publishers of data to define their own formats without
having to update software, register formats via a central authority, or
worry that two formats may interfere with each other. RDFa shares some
use cases with microformats. Whereas microformats specify both a syntax
for embedding structured data into HTML documents and a vocabulary of
specific terms for each microformat, RDFa specifies only a syntax and
relies on independent specification of terms (often called vocabularies
or taxonomies) by others. RDFa allows terms from multiple independently
developed vocabularies to be freely intermixed and is designed such that
the language can be parsed without knowledge of the specific term
vocabulary being used. Motivation: RDF/XML (Syntax) provides sufficient
flexibility to represent all of the abstract concepts in RDF. However,
it presents a number of challenges; first it is difficult or impossible
to validate documents that contain RDF/XML using XML Schemas or DTDs,
which therefore makes it difficult to import RDF/XML into other markup
languages. Whilst newer schema languages such as RELAX NG do provide a
way to validate documents that contain arbitrary RDF/XML, it will be a
while before they gain wide support. Second, even if one could add RDF/XML
directly into an XML dialect like XHTML, there would be significant data
duplication between the rendered data and the RDF/XML structured data.
It would be far better to add RDF to a document without repeating the
document's existing data. One motivation for RDFa has been to devise a
means by which documents can be augmented with metadata in a general
rather than hard-wired manner. This has been achieved by creating a
fixed set of attributes and parsing rules, but allowing those attributes
to contain properties from any of a number of the growing range of
available RDF vocabularies. The values of those properties are in most
cases the information that is already in an author's XHTML document.
Microsoft Readies Silverlight 2 Beta
Microsoft's Scott Guthrie, general manager in the Microsoft Developer
Division, has provided a list of features planned for Silverlight 2 and
the beta, planned for release during the first quarter of 2008.
Silverlight 2 will be a major update of Silverlight that focuses on
enabling Rich Internet Application (RIA) development. Silverlight 2
includes a cross-platform, cross-browser version of the .NET Framework,
and enables a rich .NET development platform that runs in the browser.
Once Silverlight 2 is installed, you can browse the Web and automatically
run rich Silverlight applications within your browser of choice; thus
includes such browsers as Internet Explorer, Firefox, Safari, and others.
For networking, Silverlight 2 backs REST (Representational State Transfer),
WS-*, and SOAP as well RSS, POX, and HTTP services. Cross-domain network
access in Silverlight 2 enables Silverlight clients to directly access
resources and data from resources on the Web. Built-in sockets networking
also is included in the beta release. Silverlight 2 features a rich .Net
base class library of functionality, such as collections, generics
threading, globalization, XML, and local storage. Rich APIs in the
product enable HTML DOM/JavaScript integration with .Net code Also featured
is Microsoft's LINQ (Language Integrated Query) technology, which provides
native query syntax for C# and Visual Basic, and LINQ to XML library
support. This enables easy transformation and querying of data; local
data caching and storage support are highlighted as well in Silverlight 2.
Developers can write Silverlight applications using a .Net language, such
as Visual Basic, C#, JavaScript, IronPython, or IronRuby. Microsoft plans
to ship support for developer/designer workflow and integration for
Silverlight in its Visual Studio 2008 and Expression Studio tools.
Division, has provided a list of features planned for Silverlight 2 and
the beta, planned for release during the first quarter of 2008.
Silverlight 2 will be a major update of Silverlight that focuses on
enabling Rich Internet Application (RIA) development. Silverlight 2
includes a cross-platform, cross-browser version of the .NET Framework,
and enables a rich .NET development platform that runs in the browser.
Once Silverlight 2 is installed, you can browse the Web and automatically
run rich Silverlight applications within your browser of choice; thus
includes such browsers as Internet Explorer, Firefox, Safari, and others.
For networking, Silverlight 2 backs REST (Representational State Transfer),
WS-*, and SOAP as well RSS, POX, and HTTP services. Cross-domain network
access in Silverlight 2 enables Silverlight clients to directly access
resources and data from resources on the Web. Built-in sockets networking
also is included in the beta release. Silverlight 2 features a rich .Net
base class library of functionality, such as collections, generics
threading, globalization, XML, and local storage. Rich APIs in the
product enable HTML DOM/JavaScript integration with .Net code Also featured
is Microsoft's LINQ (Language Integrated Query) technology, which provides
native query syntax for C# and Visual Basic, and LINQ to XML library
support. This enables easy transformation and querying of data; local
data caching and storage support are highlighted as well in Silverlight 2.
Developers can write Silverlight applications using a .Net language, such
as Visual Basic, C#, JavaScript, IronPython, or IronRuby. Microsoft plans
to ship support for developer/designer workflow and integration for
Silverlight in its Visual Studio 2008 and Expression Studio tools.
Addressing Fragments in REST
REST offers a great way to build simple applications that Create, Read,
Update, and Delete resources. But what if you want to get at part of a
resource? A database row is a simple thing, even if it enables immense
complexity. It contains named fields - no more than one to a given name,
usually conforming to a rather predictable schema. There's nothing
floating between the fields, and every row contains the same set of
fields. (They may be empty, of course, but they're clearly defined. An
XML document - or even an XML document fragment - is potentially incredibly
complicated. While many XML documents are regular and relatively simple,
the ones that aren't simply holding data as it moves between databases
are often very complicated. XML elements are kind of like fields, sure,
but [not quite...] Nonetheless, it seems like the basic operations most
people would like to perform on these documents (and other loosely-structured
resources) are the same operations people want to perform on database
records: Create, Read, Update, Delete. CRUD is everywhere, and CRUD is
good. Typically, though, an XML document is treated as a single resource.
A book might assemble itself using entities or XIncludes that pull in
chapters, of course, and those chapters could be individually addressed
as resources, but that has limits. Though it's possible, I don't think
anyone wants to write paragraphs in which each sentence is included from
a separate file using one of those mechanisms. As soon as you hit mixed
content, the entity approach breaks down anyway. (Other formats, like JSON,
don't have entities but share a few of the same problems.) So how can
developers build RESTful applications that address parts of documents?
One approach that's getting a lot of discussion in the last few days is
to add a new verb, PATCH, to HTTP... It seems to me that the problem is
not that developers want to do something that can't be expressed with a
RESTful verb - in this case, probably UPDATE. The problem is that developers
can't address the resource on which they want to work with sufficient
granularity given their current set of tools and agreements. Though I've
inveighed against the many many sins of XPointer for years, that
incredibly broken process was at least working to solve the problem of
addressing XML documents at a very fine granularity, extending the tool
most commonly used on the client side for this: fragment identifiers...
Update, and Delete resources. But what if you want to get at part of a
resource? A database row is a simple thing, even if it enables immense
complexity. It contains named fields - no more than one to a given name,
usually conforming to a rather predictable schema. There's nothing
floating between the fields, and every row contains the same set of
fields. (They may be empty, of course, but they're clearly defined. An
XML document - or even an XML document fragment - is potentially incredibly
complicated. While many XML documents are regular and relatively simple,
the ones that aren't simply holding data as it moves between databases
are often very complicated. XML elements are kind of like fields, sure,
but [not quite...] Nonetheless, it seems like the basic operations most
people would like to perform on these documents (and other loosely-structured
resources) are the same operations people want to perform on database
records: Create, Read, Update, Delete. CRUD is everywhere, and CRUD is
good. Typically, though, an XML document is treated as a single resource.
A book might assemble itself using entities or XIncludes that pull in
chapters, of course, and those chapters could be individually addressed
as resources, but that has limits. Though it's possible, I don't think
anyone wants to write paragraphs in which each sentence is included from
a separate file using one of those mechanisms. As soon as you hit mixed
content, the entity approach breaks down anyway. (Other formats, like JSON,
don't have entities but share a few of the same problems.) So how can
developers build RESTful applications that address parts of documents?
One approach that's getting a lot of discussion in the last few days is
to add a new verb, PATCH, to HTTP... It seems to me that the problem is
not that developers want to do something that can't be expressed with a
RESTful verb - in this case, probably UPDATE. The problem is that developers
can't address the resource on which they want to work with sufficient
granularity given their current set of tools and agreements. Though I've
inveighed against the many many sins of XPointer for years, that
incredibly broken process was at least working to solve the problem of
addressing XML documents at a very fine granularity, extending the tool
most commonly used on the client side for this: fragment identifiers...
OpenGIS Web Processing Service (WPS) Interface Standard Version 1.0
OGC announced that members of the Open Geospatial Consortium have
approved version 1.0 of the OpenGIS Web Processing Service (WPS)
Interface Standard. The WPS standard defines an interface that
facilitates the publishing of geospatial processes and makes it easier
to write software clients that can discover and bind to those processes.
Processes include any algorithm, calculation or model that operates on
spatially referenced raster or vector data. Publishing means making
available machine-readable binding information as well as human-readable
metadata that allows service discovery and use. A WPS can be used to
define calculations as simple as subtracting one set of spatially
referenced data from another (e.g., determining the difference in
influenza cases between two different seasons), or as complicated as a
hydrological model. The data required by the WPS can be delivered across
a network or it can be made available at the server. This interface
specification provides mechanisms to identify the spatially referenced
data required by the calculation, initiate the calculation, and manage
the output from the calculation so that the client can access it. The
OGC's WPS standard will play an important role in automating workflows
that involve geospatial data and geoprocessing services. The specification
identifies a generic mechanism to describe the data inputs required and
produced by a process. This data can be delivered across the network, or
available at the server. This data can include image data formats such
as GeoTIFF, or data exchange standards such as Geography Markup Language
(GML). Data inputs can be legitimate calls to OGC web services. For
example, a data input for an intersection operation could be a polygon
delivered in response to a WFS request, in which case the WPS data input
would be the WFS query string.
approved version 1.0 of the OpenGIS Web Processing Service (WPS)
Interface Standard. The WPS standard defines an interface that
facilitates the publishing of geospatial processes and makes it easier
to write software clients that can discover and bind to those processes.
Processes include any algorithm, calculation or model that operates on
spatially referenced raster or vector data. Publishing means making
available machine-readable binding information as well as human-readable
metadata that allows service discovery and use. A WPS can be used to
define calculations as simple as subtracting one set of spatially
referenced data from another (e.g., determining the difference in
influenza cases between two different seasons), or as complicated as a
hydrological model. The data required by the WPS can be delivered across
a network or it can be made available at the server. This interface
specification provides mechanisms to identify the spatially referenced
data required by the calculation, initiate the calculation, and manage
the output from the calculation so that the client can access it. The
OGC's WPS standard will play an important role in automating workflows
that involve geospatial data and geoprocessing services. The specification
identifies a generic mechanism to describe the data inputs required and
produced by a process. This data can be delivered across the network, or
available at the server. This data can include image data formats such
as GeoTIFF, or data exchange standards such as Geography Markup Language
(GML). Data inputs can be legitimate calls to OGC web services. For
example, a data input for an intersection operation could be a polygon
delivered in response to a WFS request, in which case the WPS data input
would be the WFS query string.
HTTP-based IETF Namespace URIs at IANA
The draft I-D "HTTP-based IETF Namespace URIs at IANA" creates a registry
and defines a procedure to allow IETF specifications to register XML
Namespace Names with IANA which are HTTP URIs and thus potentially useful
for looking up information about the namespace. Many IETF specifications
use Extensible Markup Language (XML) 1.0 (Fourth Edition) with Namespaces
in XML 1.0 (Second Edition). XML Namespace Names are URIs, and there are
many options for constructing them. One of the options is the use of HTTP
URIs -- those whose scheme is 'http:'. IETF RFC 3688 (The IETF XML
Registry) created an IANA registry for XML namespaces based on URNs,
which take on the form 'urn:ietf:params:xml:ns:foo'. RFC 3470 observes
that in the case of namespaces in the IETF standards-track documents,
it would be useful if there were some permanent part of the IETF's own
web space that could be used to mint HTTP URIs. However, it seems to
be more appropriate and in line with IETF practice to delegate such a
registry function to IANA... IANA maintains a registry page listing the
registered XML namespaces which use HTTP URIs. For each registered
namespace, the registry page includes a human-readable name for the
namespace, a link to the namespace document, and the actual namespace
URI. Namespaces created by IANA upon registration have the following form.
There is a common prefix, "http://www.iana.org/xmlns/" [...] followed
by a unique identifier. The unique identifier should be a relatively
short string of US-ASCII letters, digits, and hyphens, where a digit
cannot appear in first position and a hyphen cannot appear in first or
last position or in successive positions. In addition, the unique
identifier can end in a single '/' or '#'. XML namespaces are
case-sensitive, but all registrations are required to mutually differ
even under case-insensitive comparison. For uniformity, only lower
letters should be used. A unique identifier is proposed by the requester,
but IANA may change it as they see fit, in consultation with the
responsible Expert Reviewer. For each namespace registered, there must
be a namespace document in either HTML or XHTML which may be retrieved
using the HTTP URI which is the registered namespace name. It contains
the template information with appropriate markup. The request for creation
and registration of a HTTP XML Namespace URI is made by including a
completed registration template in the IANA Considerations section of
an Internet-Draft.
and defines a procedure to allow IETF specifications to register XML
Namespace Names with IANA which are HTTP URIs and thus potentially useful
for looking up information about the namespace. Many IETF specifications
use Extensible Markup Language (XML) 1.0 (Fourth Edition) with Namespaces
in XML 1.0 (Second Edition). XML Namespace Names are URIs, and there are
many options for constructing them. One of the options is the use of HTTP
URIs -- those whose scheme is 'http:'. IETF RFC 3688 (The IETF XML
Registry) created an IANA registry for XML namespaces based on URNs,
which take on the form 'urn:ietf:params:xml:ns:foo'. RFC 3470 observes
that in the case of namespaces in the IETF standards-track documents,
it would be useful if there were some permanent part of the IETF's own
web space that could be used to mint HTTP URIs. However, it seems to
be more appropriate and in line with IETF practice to delegate such a
registry function to IANA... IANA maintains a registry page listing the
registered XML namespaces which use HTTP URIs. For each registered
namespace, the registry page includes a human-readable name for the
namespace, a link to the namespace document, and the actual namespace
URI. Namespaces created by IANA upon registration have the following form.
There is a common prefix, "http://www.iana.org/xmlns/" [...] followed
by a unique identifier. The unique identifier should be a relatively
short string of US-ASCII letters, digits, and hyphens, where a digit
cannot appear in first position and a hyphen cannot appear in first or
last position or in successive positions. In addition, the unique
identifier can end in a single '/' or '#'. XML namespaces are
case-sensitive, but all registrations are required to mutually differ
even under case-insensitive comparison. For uniformity, only lower
letters should be used. A unique identifier is proposed by the requester,
but IANA may change it as they see fit, in consultation with the
responsible Expert Reviewer. For each namespace registered, there must
be a namespace document in either HTML or XHTML which may be retrieved
using the HTTP URI which is the registered namespace name. It contains
the template information with appropriate markup. The request for creation
and registration of a HTTP XML Namespace URI is made by including a
completed registration template in the IANA Considerations section of
an Internet-Draft.
Thursday, February 21, 2008
Lessig Considers Running for Congress
Lawrence Lessig, the cyberlaw author and advocate for free software and
online civil liberties, is considering a run for the U.S. Congress, he
announced on his blog Wednesday. Lessig, author of books such as "Free
Culture" and "Code 2.0," would run for the open House of Representatives
seat in California created by the death of Representative Tom Lantos,
a Democrat, earlier this month. A "draft Lessig" movement has popped
up online since Lantos died. Lessig said he plans to make the decision
about whether to run by about March 1, 2008. "This is a very difficult
decision," he wrote on his blog. "Thank you to everyone who has tried
to help -- both through very strong words of encouragement and very,
very strong words to dissuade. Lessig, a self-described progressive,
would run as part of his Change Congress campaign. The Stanford University
law professor announced in January that he would shift his focus to
political corruption and away from free software and free culture. He
called on lawmakers to stop accepting money from political action
committees and lobbyists, and to stop adding so-called earmarks for
special projects in appropriation legislation. Politicians need to
change "how Washington works" and to end a culture of corruption that's
based on political contributions, he said in a video at Lessig08.org.
"You know about this corruption in Washington, a corruption that doesn't
come from evil people, a corruption that comes from good people working
in a bad system," he said in the video. Progressives should work to
change the way money influences decisions in Washington, he said, "not
because this is, in some sense, the most important problem, but because
it is the first problem that has to be solved if we're going to address
these more fundamental problems later." Lessig is the founder of the
Creative Commons, which attempts to give copyright holders additional
options for licensing their work beyond all rights reserved. Lessig
has served on the boards of the Free Software Foundation, the Electronic
Frontier Foundation, the Public Library of Science, and Public Knowledge.
online civil liberties, is considering a run for the U.S. Congress, he
announced on his blog Wednesday. Lessig, author of books such as "Free
Culture" and "Code 2.0," would run for the open House of Representatives
seat in California created by the death of Representative Tom Lantos,
a Democrat, earlier this month. A "draft Lessig" movement has popped
up online since Lantos died. Lessig said he plans to make the decision
about whether to run by about March 1, 2008. "This is a very difficult
decision," he wrote on his blog. "Thank you to everyone who has tried
to help -- both through very strong words of encouragement and very,
very strong words to dissuade. Lessig, a self-described progressive,
would run as part of his Change Congress campaign. The Stanford University
law professor announced in January that he would shift his focus to
political corruption and away from free software and free culture. He
called on lawmakers to stop accepting money from political action
committees and lobbyists, and to stop adding so-called earmarks for
special projects in appropriation legislation. Politicians need to
change "how Washington works" and to end a culture of corruption that's
based on political contributions, he said in a video at Lessig08.org.
"You know about this corruption in Washington, a corruption that doesn't
come from evil people, a corruption that comes from good people working
in a bad system," he said in the video. Progressives should work to
change the way money influences decisions in Washington, he said, "not
because this is, in some sense, the most important problem, but because
it is the first problem that has to be solved if we're going to address
these more fundamental problems later." Lessig is the founder of the
Creative Commons, which attempts to give copyright holders additional
options for licensing their work beyond all rights reserved. Lessig
has served on the boards of the Free Software Foundation, the Electronic
Frontier Foundation, the Public Library of Science, and Public Knowledge.
XML 2.0? No, Seriously.
Maybe its madness to consider XML 2.0 seriously. The cost of deployment
would be significant. Simultaneously convincing a critical mass of
users to switch without turning the design process into a farce would
be very difficult. And yet, the alternatives look a little like madness
too. I found three topics on my desk simultaneously last week: (1) The
proposal to amend the character set of XML 1.0 identifiers by erratum.
(2) the proposal to deploy CURIEs, an awkward, confusing extension of
the QName concept. (3) A thread of discussion suggesting that we consider
allowing prefix undeclaration in Namespaces in XML 1.0. That's right 1.0.
We're in an odd place. XML has been more successful, and in more and
more different arenas, than could have been imagined. But... XML 1.0
is seriously broken in the area of internationalization, one of its
key strengths, because it hasn't kept pace with changes to Unicode.
QNames, originally designed as a way of creating qualified element
and attribute names have also been used in more and more different
arenas than could have been imagined. Unfortunately, the constraints
that make sense for XML element and attribute names, don't make sense,
are unacceptable, in many of the other arenas. And in XML, we learned
that it is sometimes useful to be able to take a namespace binding out
of scope. XML 1.1 addressed some of these concerns, but also introduced
backwards incompatibilities. Those incompatibilities seemed justified
at the time, although they seem so obviously unnecessary and foolish
now. In short, we botched our opportunity to fix the problem 'right'.
What to do? ... Perhaps, dare I say it, it is time to consider XML 2.0
instead. Trouble is, if XML 2.0 gets spun up as an open-ended design
exercise, it'll be crushed by the second-system effect. And if XML 2.0
gets spun up as 'only' a simplification of XML 1.0, it won't get any
traction. If XML 2.0 is to be a success, it has to offer enough in the
way of new functionality to convince people with successful XML 1.0
deployments (that's everyone, right?) that it's worth switching. At the
same time, it has to be about the same size and shape as XML 1.0 when
it's done or it'll be perceived as too big, too complicated, too much
work. With that in mind, here are some candidate requirements for XML
2.0... More Information
would be significant. Simultaneously convincing a critical mass of
users to switch without turning the design process into a farce would
be very difficult. And yet, the alternatives look a little like madness
too. I found three topics on my desk simultaneously last week: (1) The
proposal to amend the character set of XML 1.0 identifiers by erratum.
(2) the proposal to deploy CURIEs, an awkward, confusing extension of
the QName concept. (3) A thread of discussion suggesting that we consider
allowing prefix undeclaration in Namespaces in XML 1.0. That's right 1.0.
We're in an odd place. XML has been more successful, and in more and
more different arenas, than could have been imagined. But... XML 1.0
is seriously broken in the area of internationalization, one of its
key strengths, because it hasn't kept pace with changes to Unicode.
QNames, originally designed as a way of creating qualified element
and attribute names have also been used in more and more different
arenas than could have been imagined. Unfortunately, the constraints
that make sense for XML element and attribute names, don't make sense,
are unacceptable, in many of the other arenas. And in XML, we learned
that it is sometimes useful to be able to take a namespace binding out
of scope. XML 1.1 addressed some of these concerns, but also introduced
backwards incompatibilities. Those incompatibilities seemed justified
at the time, although they seem so obviously unnecessary and foolish
now. In short, we botched our opportunity to fix the problem 'right'.
What to do? ... Perhaps, dare I say it, it is time to consider XML 2.0
instead. Trouble is, if XML 2.0 gets spun up as an open-ended design
exercise, it'll be crushed by the second-system effect. And if XML 2.0
gets spun up as 'only' a simplification of XML 1.0, it won't get any
traction. If XML 2.0 is to be a success, it has to offer enough in the
way of new functionality to convince people with successful XML 1.0
deployments (that's everyone, right?) that it's worth switching. At the
same time, it has to be about the same size and shape as XML 1.0 when
it's done or it'll be perceived as too big, too complicated, too much
work. With that in mind, here are some candidate requirements for XML
2.0... More Information
Infiniflow: Distributed Application Server Based on OSGi and SCA
Paremus recently released version 1.2 of Infiniflow, a next-generation
distributed application server based on OSGi and SCA. Paremus Marketing
Manager Andrew Rowney explained that Infiniflow was based upon OSGi and
SCA, and that it follows an application server paradigm -- a component
is written as a series of OSGi modules, it is linked to external
services through the SCA bindings, and Infiniflow provides life-cycle
management, monitoring, scaling and fault-recovery for any application
deployed on it. Rowney also described some best practices for application
development with Infiniflow: To take advantage of the full capabilities
of Infiniflow, an application needs to be presented as a composite
application rather than a single runtime entity, with different parts
of the processing requirements being handled in separate components
(OSGi bundles). A good example is where a part of the composite
application contains an intensive calculation that can be run in parallel
to reduce the overall processing time. For this type of applications the
developer is able to specify that Infiniflow should duplicate the bundle
that runs the calculation, instantiating as many copies as possible in
order to calculate the final result as quickly as possible... Infiniflow
itself is built using OSGi, and wired together using SCA System
descriptions. It has a Model-Driven Architecture: to reduce operational
complexity, application runtimes can only be modified through their SCA
System descriptor, and all interactions with the descriptor are secured
and audited An Infiniflow Service Fabric consists of a number of
Infiniflow containers -- OSGi-enabled JVM's -- which are able to
dynamically install/start/stop/uninstall code packaged in the OSGi
bundles referenced from the SCA System document...
distributed application server based on OSGi and SCA. Paremus Marketing
Manager Andrew Rowney explained that Infiniflow was based upon OSGi and
SCA, and that it follows an application server paradigm -- a component
is written as a series of OSGi modules, it is linked to external
services through the SCA bindings, and Infiniflow provides life-cycle
management, monitoring, scaling and fault-recovery for any application
deployed on it. Rowney also described some best practices for application
development with Infiniflow: To take advantage of the full capabilities
of Infiniflow, an application needs to be presented as a composite
application rather than a single runtime entity, with different parts
of the processing requirements being handled in separate components
(OSGi bundles). A good example is where a part of the composite
application contains an intensive calculation that can be run in parallel
to reduce the overall processing time. For this type of applications the
developer is able to specify that Infiniflow should duplicate the bundle
that runs the calculation, instantiating as many copies as possible in
order to calculate the final result as quickly as possible... Infiniflow
itself is built using OSGi, and wired together using SCA System
descriptions. It has a Model-Driven Architecture: to reduce operational
complexity, application runtimes can only be modified through their SCA
System descriptor, and all interactions with the descriptor are secured
and audited An Infiniflow Service Fabric consists of a number of
Infiniflow containers -- OSGi-enabled JVM's -- which are able to
dynamically install/start/stop/uninstall code packaged in the OSGi
bundles referenced from the SCA System document...
XML Daily Newslink. Wednesday, 20 February 2008
Extreme transaction processing (XTP) is being added to complex event
processing (CEP) in service-oriented architecture (SOA) implementations
for the financial services industry, explains David Chappell, vice
president and chief technologist for SOA at Oracle Corp. Chappell:
"What we're seeing is that SOA coupled with a class of applications
coined as extreme transaction processing or XTP is the future for
financial services infrastructure. So IT continues to be seen as the
enabler. We've seen some supporting data from Gartner/DataQuest that
IT spending in financial services is going to reach $566 billion by
2010. Where SOA comes into the picture is that it enables IT to deliver
new business services faster, while leveraging existing systems. At
the same time the financial institutions are pushing limits that require
more processing capability yet at the same time they don't want to see
an exponential rise in their investment in hardware. So the extreme
transaction processing class of applications has been most notably seen
in areas such as fraud detection, risk computation and stock trade
resolution... What XTP does is allow transactions to occur in memory
and not against the backend systems directly due to the need for extremely
fast response rates, but still including transactional integrity. So
think of classes of applications that need to handle large volumes of
data that need to be absorbed, correlated and acted upon. Typically
that data processed by XTP applications comes in the form of large
numbers of events and usually represents data that changes frequently...
once the pattern matching engine, whether it's built directly into the
XTP application itself or is identified by the complex event processing
engine, is it identifies an event of significance such as ATM withdrawal
fraud. Say for example your ATM card is used in different ATM machines
or is used to make purchases in three or four states or even different
countries within a matter of minutes, that's usually a flag that some
kind of fraud is going on. Once that kind of a situation is detected
then an SOA process in BPEL can be kicked off to make the proper
notification, send alerts to Business Activity Monitoring dashboards...
processing (CEP) in service-oriented architecture (SOA) implementations
for the financial services industry, explains David Chappell, vice
president and chief technologist for SOA at Oracle Corp. Chappell:
"What we're seeing is that SOA coupled with a class of applications
coined as extreme transaction processing or XTP is the future for
financial services infrastructure. So IT continues to be seen as the
enabler. We've seen some supporting data from Gartner/DataQuest that
IT spending in financial services is going to reach $566 billion by
2010. Where SOA comes into the picture is that it enables IT to deliver
new business services faster, while leveraging existing systems. At
the same time the financial institutions are pushing limits that require
more processing capability yet at the same time they don't want to see
an exponential rise in their investment in hardware. So the extreme
transaction processing class of applications has been most notably seen
in areas such as fraud detection, risk computation and stock trade
resolution... What XTP does is allow transactions to occur in memory
and not against the backend systems directly due to the need for extremely
fast response rates, but still including transactional integrity. So
think of classes of applications that need to handle large volumes of
data that need to be absorbed, correlated and acted upon. Typically
that data processed by XTP applications comes in the form of large
numbers of events and usually represents data that changes frequently...
once the pattern matching engine, whether it's built directly into the
XTP application itself or is identified by the complex event processing
engine, is it identifies an event of significance such as ATM withdrawal
fraud. Say for example your ATM card is used in different ATM machines
or is used to make purchases in three or four states or even different
countries within a matter of minutes, that's usually a flag that some
kind of fraud is going on. Once that kind of a situation is detected
then an SOA process in BPEL can be kicked off to make the proper
notification, send alerts to Business Activity Monitoring dashboards...
ODF Standard Editor Calls for Cooperation with OOXML
The teams developing ODF (OpenDocument Format) and OOXML (Office Open
XML) standards should work together, evolving the two in parallel, the
editor of the ODF standard said Tuesday in an open letter to the
standards-setting community. The Microsoft-sponsored OOXML document
format is just days away from a critical meeting that will influence
whether the International Organization for Standardization (ISO) will
adopt it as a standard as its rival ODF was adopted in May 2006.
Relations between supporters of the two formats are, for the most part,
combative rather than cordial. Patrick Durusau, ISO project editor for
ODF, or ISO/IEC 26300 as it is known there, thinks supporters of the
two formats would be more productive if they allowed the formats to
co-evolve, he wrote in his open letter . Durusau thoughtfully avoided
the ODF and OOXML formats for his letter, choosing instead PDF, itself
adopted as an ISO standard in December. From Durusau's "Co-Evolving
OpenXML And OpenDocument Format": "If we had a co-evolutionary environment,
one where the proponents of OpenXML and OpenDocument, their respective
organizations, national bodies and others interested groups could meet
to discuss the future of those proposals, the future revisions of both
would likely be quite different. Co-evolution means that the standards
will evolve based on the influence of each other and their respective
user communities. Both remain completely independent and neither is
subordinate to the other. What is currently lacking is a neutral forum
in which proponents can meet and learn from each other. Creating such
an environment is going to take time and effort so I would like to
suggest a first step towards fostering co-evolution between OpenXML
and OpenDocument..."
XML) standards should work together, evolving the two in parallel, the
editor of the ODF standard said Tuesday in an open letter to the
standards-setting community. The Microsoft-sponsored OOXML document
format is just days away from a critical meeting that will influence
whether the International Organization for Standardization (ISO) will
adopt it as a standard as its rival ODF was adopted in May 2006.
Relations between supporters of the two formats are, for the most part,
combative rather than cordial. Patrick Durusau, ISO project editor for
ODF, or ISO/IEC 26300 as it is known there, thinks supporters of the
two formats would be more productive if they allowed the formats to
co-evolve, he wrote in his open letter . Durusau thoughtfully avoided
the ODF and OOXML formats for his letter, choosing instead PDF, itself
adopted as an ISO standard in December. From Durusau's "Co-Evolving
OpenXML And OpenDocument Format": "If we had a co-evolutionary environment,
one where the proponents of OpenXML and OpenDocument, their respective
organizations, national bodies and others interested groups could meet
to discuss the future of those proposals, the future revisions of both
would likely be quite different. Co-evolution means that the standards
will evolve based on the influence of each other and their respective
user communities. Both remain completely independent and neither is
subordinate to the other. What is currently lacking is a neutral forum
in which proponents can meet and learn from each other. Creating such
an environment is going to take time and effort so I would like to
suggest a first step towards fostering co-evolution between OpenXML
and OpenDocument..."
ISO News: Ballot Resolution Meeting on ISO/IEC DIS 29500 Standard
National delegations from thirty-seven (37) countries will be
participating in a ballot resolution meeting in Geneva, Switzerland,
on 25-29 February 2008 on the draft international standard "ISO/IEC
DIS 29500, Information Technology -- Office Open XML File Formats."
ISO/IEC DIS 29500 is a proposed standard for word-processing documents,
presentations and spreadsheets that is intended to be implemented by
multiple applications on multiple platforms. According to the
submitters of the document, one of its objectives is to ensure the
long-term preservation of documents created over the last two decades
using programmes that are becoming incompatible with continuing
advances in the field of information technology. The objective of the
ballot resolution meeting (BRM) will be to review and seek consensus
on possible modifications to the document in light of the comments
received along with votes cast during a five-month ballot on the draft
which ended on 2 September 2007... No decision on publication will be
taken at the meeting itself. Following the BRM, the 87 national member
bodies that voted in the 2 September ballot will have 30 days (until
29 March 2008) to examine the actions taken in response to the comments
and to reconsider their vote if they wish. If the modifications proposed
are such that national bodies then wish to withdraw their negative
votes, or turn abstentions into positive votes, and the acceptance
criteria are then met, the standard may proceed to publication. The
BRM is being organized by subcommittee SC 34, Document description and
processing languages, of the joint technical committee JTC 1, Information
technology. JTC 1 is one of the most experienced and productive of ISO
and IEC technical committees, having developed some 2 150 widely and
globally used international standards and related documents.
Approximately 4 200 comments were received during last year's ballot.
By grouping and by eliminating redundancies, these have been edited by
SC 34 experts down to 1100 comments for processing during the five
days of the BRM. The task will be carried out by 120 participants who
have registered for the meeting. They comprise members of the 37
national delegations, plus representatives of Ecma International, the
computer manufacturers' association that submitted ISO/IEC DIS 29500
for adoption by JTC 1, plus officers of the ISO/IEC Information
Technology Task Force (ITTF) which is responsible for the planning and
coordination of JTC 1 work. More Information
participating in a ballot resolution meeting in Geneva, Switzerland,
on 25-29 February 2008 on the draft international standard "ISO/IEC
DIS 29500, Information Technology -- Office Open XML File Formats."
ISO/IEC DIS 29500 is a proposed standard for word-processing documents,
presentations and spreadsheets that is intended to be implemented by
multiple applications on multiple platforms. According to the
submitters of the document, one of its objectives is to ensure the
long-term preservation of documents created over the last two decades
using programmes that are becoming incompatible with continuing
advances in the field of information technology. The objective of the
ballot resolution meeting (BRM) will be to review and seek consensus
on possible modifications to the document in light of the comments
received along with votes cast during a five-month ballot on the draft
which ended on 2 September 2007... No decision on publication will be
taken at the meeting itself. Following the BRM, the 87 national member
bodies that voted in the 2 September ballot will have 30 days (until
29 March 2008) to examine the actions taken in response to the comments
and to reconsider their vote if they wish. If the modifications proposed
are such that national bodies then wish to withdraw their negative
votes, or turn abstentions into positive votes, and the acceptance
criteria are then met, the standard may proceed to publication. The
BRM is being organized by subcommittee SC 34, Document description and
processing languages, of the joint technical committee JTC 1, Information
technology. JTC 1 is one of the most experienced and productive of ISO
and IEC technical committees, having developed some 2 150 widely and
globally used international standards and related documents.
Approximately 4 200 comments were received during last year's ballot.
By grouping and by eliminating redundancies, these have been edited by
SC 34 experts down to 1100 comments for processing during the five
days of the BRM. The task will be carried out by 120 participants who
have registered for the meeting. They comprise members of the 37
national delegations, plus representatives of Ecma International, the
computer manufacturers' association that submitted ISO/IEC DIS 29500
for adoption by JTC 1, plus officers of the ISO/IEC Information
Technology Task Force (ITTF) which is responsible for the planning and
coordination of JTC 1 work. More Information
Wednesday, February 20, 2008
GRDDL: Gleaning Information From Embedded Metadata
This article explains how to put GRDDL-enabled agents to the task of
extracting valuable information from machine-processable metadata
embedded in documents -- courtesy of prevailing semantic web standards.
HTML and XHTML traditionally have had only modest support for metadata
tags. The World Wide Web Consortium (W3C) is working on including richer
metadata support in HTML/XHTML with emerging standards such as RDF with
attributes (RDFa), embedded RDF (eRDF), and so on. These standards allow
more specific metadata to be attached to different structural and
presentation elements, which provides a unified information resource.
Gleaning Resource Descriptions from Dialects of Languages (GRDDL,
pronounced griddle) offers a solution to the embedded metadata problem
in a flexible, inclusive, and forward-compatible way. It allows the
extraction of standard forms of metadata (RDF) from a variety of sources
within a document. People usually associate XHTML with GRDDL, but it is
worth noting that GRDDL is useful for extracting standardized RDF
metadata from other XML structures as well. GRDDL theoretically supports
a series of naming conventions and standard transformations, but it does
not require everyone to agree to particular markup strategies. It allows
you to normalize metadata extraction from documents using RDFa,
microformats, eRDF, or even custom mark-up schemes. The trick is to
identify the document as a GRDDL-aware source by specifying an HTML
metadata profile. The profile indicates to any GRDDL-aware agents that
the standard GRDDL profile applies. Anyone wishing to extract metadata
from the document should identify any relevant 'link' tags with a 'rel'
attribute of transformation and apply it to the document itself. This
approach avoids the conventional problem of screen scraping, where the
client has to figure out how to extract information. With GRDDL, the
publisher indicates a simple, reusable mechanism to extract relevant
information. While there is currently no direct support for GRDDL in
any major browser, that situation is likely to change in the near future.
Until then, it is not at all difficult to put a GRDDL-aware proxy in
between your browser and GRDDL-enabled pages, which the Piggy Bank
FireFox extension from MIT's SIMILE Project does.
extracting valuable information from machine-processable metadata
embedded in documents -- courtesy of prevailing semantic web standards.
HTML and XHTML traditionally have had only modest support for metadata
tags. The World Wide Web Consortium (W3C) is working on including richer
metadata support in HTML/XHTML with emerging standards such as RDF with
attributes (RDFa), embedded RDF (eRDF), and so on. These standards allow
more specific metadata to be attached to different structural and
presentation elements, which provides a unified information resource.
Gleaning Resource Descriptions from Dialects of Languages (GRDDL,
pronounced griddle) offers a solution to the embedded metadata problem
in a flexible, inclusive, and forward-compatible way. It allows the
extraction of standard forms of metadata (RDF) from a variety of sources
within a document. People usually associate XHTML with GRDDL, but it is
worth noting that GRDDL is useful for extracting standardized RDF
metadata from other XML structures as well. GRDDL theoretically supports
a series of naming conventions and standard transformations, but it does
not require everyone to agree to particular markup strategies. It allows
you to normalize metadata extraction from documents using RDFa,
microformats, eRDF, or even custom mark-up schemes. The trick is to
identify the document as a GRDDL-aware source by specifying an HTML
metadata profile. The profile indicates to any GRDDL-aware agents that
the standard GRDDL profile applies. Anyone wishing to extract metadata
from the document should identify any relevant 'link' tags with a 'rel'
attribute of transformation and apply it to the document itself. This
approach avoids the conventional problem of screen scraping, where the
client has to figure out how to extract information. With GRDDL, the
publisher indicates a simple, reusable mechanism to extract relevant
information. While there is currently no direct support for GRDDL in
any major browser, that situation is likely to change in the near future.
Until then, it is not at all difficult to put a GRDDL-aware proxy in
between your browser and GRDDL-enabled pages, which the Piggy Bank
FireFox extension from MIT's SIMILE Project does.
Access Control for Cross-site Requests
W3C announced that the Web Application Formats (WAF) Working Group has
released a new snapshot of the editor's draft of "Access Control for
Cross-site Requests." The WAF Working Group is part of the Rich Web
Clients Activity in the W3C Interaction Domain. It includes recent
HTTP header name changes and incorporates a new proposal for limiting
the amount of requests in case of non-GET methods to various different
URIs which share the same origin. In addition to those technical
changes it also makes the (until now) implicit requirements and use
cases explicit by listing them in an appendix and contains a short
FAQ on design decisions. Summary: "In Web application technologies
that follow this pattern, network requests typically use ambient
authentication and session management information, including HTTP
authentication and cookie information. This specification extends
this model in several ways: (1) Web applications are enabled to
annotate the data that is returned in response to an HTTP request with
a set of origins that should be permitted to read that information by
way of the user's Web browser. The policy expressed through this set
of origins is enforced on the client. (2) Web browsers are enabled to
discover whether a target resource is prepared to accept cross-site
HTTP requests using non-GET methods from a set of origins. The policy
expressed through this set of origins is enforced on the client. (3)
Server side applications are enabled to discover that an HTTP request
was deemed a cross-site request by the client Web browser, through
the Access-Control-Origin HTTP header. This extension enables server
side applications to enforce limitations on the cross-site requests
that they are willing to service. This specification is a building
block for other specifications, so-called hosting specifications,
which will define the precise model by which this specification is
used. Among others, such specifications are likely to include
XMLHttpRequest Level 2, XBL 2.0, and HTML 5 (for its server-sent
events feature). According to the editor's note: "We expect the next
draft to go to Last Call so hereby we're soliciting input, once again,
from the Forms WG, HTML WG, HTTP WG, TAG, Web API WG, and Web Security
Context WG..."
released a new snapshot of the editor's draft of "Access Control for
Cross-site Requests." The WAF Working Group is part of the Rich Web
Clients Activity in the W3C Interaction Domain. It includes recent
HTTP header name changes and incorporates a new proposal for limiting
the amount of requests in case of non-GET methods to various different
URIs which share the same origin. In addition to those technical
changes it also makes the (until now) implicit requirements and use
cases explicit by listing them in an appendix and contains a short
FAQ on design decisions. Summary: "In Web application technologies
that follow this pattern, network requests typically use ambient
authentication and session management information, including HTTP
authentication and cookie information. This specification extends
this model in several ways: (1) Web applications are enabled to
annotate the data that is returned in response to an HTTP request with
a set of origins that should be permitted to read that information by
way of the user's Web browser. The policy expressed through this set
of origins is enforced on the client. (2) Web browsers are enabled to
discover whether a target resource is prepared to accept cross-site
HTTP requests using non-GET methods from a set of origins. The policy
expressed through this set of origins is enforced on the client. (3)
Server side applications are enabled to discover that an HTTP request
was deemed a cross-site request by the client Web browser, through
the Access-Control-Origin HTTP header. This extension enables server
side applications to enforce limitations on the cross-site requests
that they are willing to service. This specification is a building
block for other specifications, so-called hosting specifications,
which will define the precise model by which this specification is
used. Among others, such specifications are likely to include
XMLHttpRequest Level 2, XBL 2.0, and HTML 5 (for its server-sent
events feature). According to the editor's note: "We expect the next
draft to go to Last Call so hereby we're soliciting input, once again,
from the Forms WG, HTML WG, HTTP WG, TAG, Web API WG, and Web Security
Context WG..."
Web Services Connector for JMX Enters Public Review
The JSR 262 has has now entered the Public Review phase. New JMX types
supported for MBean operations: NotificationResult,
NotificationFilterSupport, AttributeChangeNotificationFilter,
MBeanServerNotificationFilter. This allows the JSR 262 connector to
support the new Event Service being defined by JSR 255, which has
MBean operations that use those types. JSR 262 defines a way to use
Web Services to access JMX instrumentation remotely. It provides a
way to use the server part of the JMX Remote API to create a Web Services
agent exposing JMX instrumentation, and a way to use the client part
of the API to access the instrumentation remotely from a Java
application. It also specifies the WSDL definitions used so that the
instrumentation will be available from clients that are not based on
the Java platform, or from Java platform clients accessing the
instrumentation directly using the JAX-RPC API. The Web Services
Connector for Java Management Extensions (JMX) Agents Reference
Implementation Project develops and evolves the reference
implementation of JSR 262 specification. The JSR 262 defines a
connector for JMX that uses Web Services to make JMX instrumentation
available remotely. JMX Connector semantics are preserved when
connecting from a JMX Client. WS-Management standard from the DMTF
is the protocol in use in the connector. This Connector allows WS-Man
native clients to interoperate with JMX Agent. Such clients can be
written in Java language or not (C, C#, JavaScript, Perl, ...). The
JMX technology was developed through the Java Community Process (JCP)
program, and was one of the earliest JSRs (JSR 3). It was subsequently
extended by the JMX Remote API (JSR 160). The future evolutions of
both JSRs have now been merged into a single JSR to define version
2.0 of the JMX specification (JSR 255). A management interface, as
defined by the JMX specification, is composed of named objects called
Management Beans, or MBeans. MBeans are registered with an ObjectName
in an MBean server. To manage a resource or resources in your
application, you create an MBean that defines its management
interface, and then register that MBean in your MBean server. The
content of the MBean server can then be exposed through various
protocols, implemented by protocol connectors, or by protocol adaptors.
supported for MBean operations: NotificationResult,
NotificationFilterSupport, AttributeChangeNotificationFilter,
MBeanServerNotificationFilter. This allows the JSR 262 connector to
support the new Event Service being defined by JSR 255, which has
MBean operations that use those types. JSR 262 defines a way to use
Web Services to access JMX instrumentation remotely. It provides a
way to use the server part of the JMX Remote API to create a Web Services
agent exposing JMX instrumentation, and a way to use the client part
of the API to access the instrumentation remotely from a Java
application. It also specifies the WSDL definitions used so that the
instrumentation will be available from clients that are not based on
the Java platform, or from Java platform clients accessing the
instrumentation directly using the JAX-RPC API. The Web Services
Connector for Java Management Extensions (JMX) Agents Reference
Implementation Project develops and evolves the reference
implementation of JSR 262 specification. The JSR 262 defines a
connector for JMX that uses Web Services to make JMX instrumentation
available remotely. JMX Connector semantics are preserved when
connecting from a JMX Client. WS-Management standard from the DMTF
is the protocol in use in the connector. This Connector allows WS-Man
native clients to interoperate with JMX Agent. Such clients can be
written in Java language or not (C, C#, JavaScript, Perl, ...). The
JMX technology was developed through the Java Community Process (JCP)
program, and was one of the earliest JSRs (JSR 3). It was subsequently
extended by the JMX Remote API (JSR 160). The future evolutions of
both JSRs have now been merged into a single JSR to define version
2.0 of the JMX specification (JSR 255). A management interface, as
defined by the JMX specification, is composed of named objects called
Management Beans, or MBeans. MBeans are registered with an ObjectName
in an MBean server. To manage a resource or resources in your
application, you create an MBean that defines its management
interface, and then register that MBean in your MBean server. The
content of the MBean server can then be exposed through various
protocols, implemented by protocol connectors, or by protocol adaptors.
RESTful SOA Using XML
Service Oriented Architecture (SOA) is used in companies that have
large numbers of applications for employees in different departments
with varying responsibilities. Many of these applications share
functionalities, but the combinations of functionalities, user-interface
specifics, and usability requirements differ. Like many enterprise
architectures, SOA follows a multitier model, but it doesn't stop there.
Within the server, functionalities are divided over separate services.
A client can consume one or more of the services, and one service can
be consumed by many clients. The result is a loosely coupled architecture
that propagates the reusability of existing software. SOA fits
particularly well in large companies that have several hundred poorly
integrated applications and that need to clean up their IT
infrastructures. SOA is a proven practice, capable of working effectively
in large environments. Adapters can to translate legacy applications to
services that integrate as backends to modern applications. Middleware
technology is available to orchestrate services and control access to
specific functionalities in the service. Because the need for SOAs is
highest in this area, vendors of middleware technology typically focus
their products toward large and heavyweight solutions. Usually, SOA is
implemented with the SOAP protocol, described by a Web Services
Description Language (WSDL) document. Although many developer tools make
it relatively easy to work with SOAP and WSDL, I consider them heavyweight
technology, because they're hard to work with if you don't use those
tools. You can implement SOA just as well by sending simple messages
over Hypertext Transfer Protocol (HTTP). Basically, this is what RESTful
Web services do. Representational State Transfer (REST; the name was
coined by Roy Fielding) isn't a protocol or technology: It's an
architectural style. REST, a lightweight alternative to SOAP, is resource
oriented rather than action oriented. It's often summarized as bringing
back remote procedure calls to GET, POST, PUT, and DELETE statements
using HTTP. In my opinion, this is the second important step. More Information
large numbers of applications for employees in different departments
with varying responsibilities. Many of these applications share
functionalities, but the combinations of functionalities, user-interface
specifics, and usability requirements differ. Like many enterprise
architectures, SOA follows a multitier model, but it doesn't stop there.
Within the server, functionalities are divided over separate services.
A client can consume one or more of the services, and one service can
be consumed by many clients. The result is a loosely coupled architecture
that propagates the reusability of existing software. SOA fits
particularly well in large companies that have several hundred poorly
integrated applications and that need to clean up their IT
infrastructures. SOA is a proven practice, capable of working effectively
in large environments. Adapters can to translate legacy applications to
services that integrate as backends to modern applications. Middleware
technology is available to orchestrate services and control access to
specific functionalities in the service. Because the need for SOAs is
highest in this area, vendors of middleware technology typically focus
their products toward large and heavyweight solutions. Usually, SOA is
implemented with the SOAP protocol, described by a Web Services
Description Language (WSDL) document. Although many developer tools make
it relatively easy to work with SOAP and WSDL, I consider them heavyweight
technology, because they're hard to work with if you don't use those
tools. You can implement SOA just as well by sending simple messages
over Hypertext Transfer Protocol (HTTP). Basically, this is what RESTful
Web services do. Representational State Transfer (REST; the name was
coined by Roy Fielding) isn't a protocol or technology: It's an
architectural style. REST, a lightweight alternative to SOAP, is resource
oriented rather than action oriented. It's often summarized as bringing
back remote procedure calls to GET, POST, PUT, and DELETE statements
using HTTP. In my opinion, this is the second important step. More Information
Codecs, Metadata, and Addressing: Video on the Web Workshop Report
W3C announced that a published Report on the W3C Video on the Web
Workshop is now available. Thirty-seven organizations discussed video
and audio codecs, spatial and temporal addressing, metadata, digital
rights management, accessibility, and other topics related to ensuring
the success of video as a "first class citizen" of the Web. W3C thanks
Cisco for hosting the Workshop, which took place 12-13 December 2007
simultaneously in San Jose, California and Brussels, Belgium. Five
major areas of possible work emerged from the Workshop: video codecs,
metadata, addressing, cross-group coordination and best practices for
video content. The W3C team will work with interested parties to
evaluate the situation with regards to video codecs, and what, if
anything, W3C can do to ensure that codecs, containers, etc. for the
Web encourage the broadest possible adoption and interoperability. As
for metadata, one direction would be to create a Working Group tasked
to come up with a simple common ontology between the existing standards
which defines a mapping between this ontology and existing standards
and defines a roadmap for extending the ontology, including information
related to copyright and licensing rights. W3C should also consider
creating a Group to investigate the important issue of addressing. The
goal would be to: (1) provide a URI syntax for temporal and spatial
addressing; (2) investigate how to attach metadata information to
spatial and temporal regions when using RDF or other existing
specifications, such as SMIL or SVG. A Group working on guidelines and
best practices for effective video and audio content on the Web could
be useful, and would look at the entire existing delivery chain from
producers to end-users, from content delivery, to metadata management,
accessibility or device independence. Also available online: forty-two
position papers and Workshop minutes.
Workshop is now available. Thirty-seven organizations discussed video
and audio codecs, spatial and temporal addressing, metadata, digital
rights management, accessibility, and other topics related to ensuring
the success of video as a "first class citizen" of the Web. W3C thanks
Cisco for hosting the Workshop, which took place 12-13 December 2007
simultaneously in San Jose, California and Brussels, Belgium. Five
major areas of possible work emerged from the Workshop: video codecs,
metadata, addressing, cross-group coordination and best practices for
video content. The W3C team will work with interested parties to
evaluate the situation with regards to video codecs, and what, if
anything, W3C can do to ensure that codecs, containers, etc. for the
Web encourage the broadest possible adoption and interoperability. As
for metadata, one direction would be to create a Working Group tasked
to come up with a simple common ontology between the existing standards
which defines a mapping between this ontology and existing standards
and defines a roadmap for extending the ontology, including information
related to copyright and licensing rights. W3C should also consider
creating a Group to investigate the important issue of addressing. The
goal would be to: (1) provide a URI syntax for temporal and spatial
addressing; (2) investigate how to attach metadata information to
spatial and temporal regions when using RDF or other existing
specifications, such as SMIL or SVG. A Group working on guidelines and
best practices for effective video and audio content on the Web could
be useful, and would look at the entire existing delivery chain from
producers to end-users, from content delivery, to metadata management,
accessibility or device independence. Also available online: forty-two
position papers and Workshop minutes.
Universal Middleware: What's Happening With OSGi and Why You Should Care
The Open Services Gateway Initiative (OSGi) Alliance is working to
realize the vision of a "universal middleware" that will address issues
such as application packaging, versioning, deployment, publication,
and discovery. In this article we'll examine the need for the kind of
container model provided by the OSGi, outline the capabilities it would
provide, and discuss its relationship to complementary technologies
such as SOA, SCA, and Spring. Enterprise software is often composed of
large amounts of complex interdependent logic that makes it hard to
adapt readily to changes in requirements from the business. You can
enable this kind of agility by following a Service Oriented Architecture
(SOA) pattern that refactors a system into application modules grouped
by business functions that expose their public functionality as services
(interfaces)... we'll explain how an Open Services Gateway initiative
(OSGi) container would solve them. We'll begin with an introduction
to the OSGi's solution to the problem, concepts, and platform, and
then we'll delve into the evolution of the OSGi from its past in the
world of embedded devices to its future in enterprise systems. We'll
also explain the relationship between the OSGi and other initiatives,
containers, and technologies to provide a comprehensive picture of
the OSGi from the perspective of software development... Conceptually
both SCA and OSGi provide a composite model for assembling a
services-based composite application that can expose some services
to the external world as well as invoke external services. In OSGi
R4, declarative services define a model to declare a component in
XML, capturing its implementation and references. Besides SCA-like
component-level information, the OSGi model captures additional
information to control runtime behavior. For example, R4 provides
bind/unbind methods to track the lifecycle or manage target services
dynamically. SCA metadata defines wires between components or from a
component to a reference in its composite model...
realize the vision of a "universal middleware" that will address issues
such as application packaging, versioning, deployment, publication,
and discovery. In this article we'll examine the need for the kind of
container model provided by the OSGi, outline the capabilities it would
provide, and discuss its relationship to complementary technologies
such as SOA, SCA, and Spring. Enterprise software is often composed of
large amounts of complex interdependent logic that makes it hard to
adapt readily to changes in requirements from the business. You can
enable this kind of agility by following a Service Oriented Architecture
(SOA) pattern that refactors a system into application modules grouped
by business functions that expose their public functionality as services
(interfaces)... we'll explain how an Open Services Gateway initiative
(OSGi) container would solve them. We'll begin with an introduction
to the OSGi's solution to the problem, concepts, and platform, and
then we'll delve into the evolution of the OSGi from its past in the
world of embedded devices to its future in enterprise systems. We'll
also explain the relationship between the OSGi and other initiatives,
containers, and technologies to provide a comprehensive picture of
the OSGi from the perspective of software development... Conceptually
both SCA and OSGi provide a composite model for assembling a
services-based composite application that can expose some services
to the external world as well as invoke external services. In OSGi
R4, declarative services define a model to declare a component in
XML, capturing its implementation and references. Besides SCA-like
component-level information, the OSGi model captures additional
information to control runtime behavior. For example, R4 provides
bind/unbind methods to track the lifecycle or manage target services
dynamically. SCA metadata defines wires between components or from a
component to a reference in its composite model...
Conference Event Package Data Format Extension for Centralized
Members of the IETF Centralized Conferencing (XCON) Working Group have
published an initial Internet Draft for "Conference Event Package Data
Format Extension for Centralized Conferencing (XCON)." The XCON
framework defines a notification service that provides updates about
a conference instance's state to authorized parties using a notification
protocol. The "Data Format Extension" memo specifies a notification
mechanism for centralized conferencing which reuses the SIP (Session
Initiation Protocol) event package for conference state. Additionally,
the notification protocol specified in this document supports all the
data defined in the XCON data model (i.e., data model as originally
defined in RFC 4575) plus all the extensions, plus a partial notification
mechanism based on XML patch operations. Section 5.4 provides an XML
Schema for Partial Notifications. Generating large notifications to
report small changes does not meet the efficiency requirements of some
bandwidth-constrained environments. The partial notifications mechanism
specified in this section is a more efficient way to report changes in
the conference state. In order to obtain notifications from a conference
server's notification service, a client subscribes to the 'conference'
event package at the server as specified in RFC 4575. The NOTIFY
requests within this event package can carry an XML document in the
"application/conference-info+xml" format. Additionally, per this
specification, NOTIFY requests can also carry XML documents in the
"application/xcon-conference-info+xml" and the
"application/xcon-conference-info-diff" formats. A document in the
"application/xcon-conference-info+xml" format provides the user agent
with the whole state of a conference instance. A document in the
"application/ xcon-conference-info-diff+xml" format provides the user
agent with the changes the state of the conference instance has
experimented since the last notification sent to the user agent.
published an initial Internet Draft for "Conference Event Package Data
Format Extension for Centralized Conferencing (XCON)." The XCON
framework defines a notification service that provides updates about
a conference instance's state to authorized parties using a notification
protocol. The "Data Format Extension" memo specifies a notification
mechanism for centralized conferencing which reuses the SIP (Session
Initiation Protocol) event package for conference state. Additionally,
the notification protocol specified in this document supports all the
data defined in the XCON data model (i.e., data model as originally
defined in RFC 4575) plus all the extensions, plus a partial notification
mechanism based on XML patch operations. Section 5.4 provides an XML
Schema for Partial Notifications. Generating large notifications to
report small changes does not meet the efficiency requirements of some
bandwidth-constrained environments. The partial notifications mechanism
specified in this section is a more efficient way to report changes in
the conference state. In order to obtain notifications from a conference
server's notification service, a client subscribes to the 'conference'
event package at the server as specified in RFC 4575. The NOTIFY
requests within this event package can carry an XML document in the
"application/conference-info+xml" format. Additionally, per this
specification, NOTIFY requests can also carry XML documents in the
"application/xcon-conference-info+xml" and the
"application/xcon-conference-info-diff" formats. A document in the
"application/xcon-conference-info+xml" format provides the user agent
with the whole state of a conference instance. A document in the
"application/ xcon-conference-info-diff+xml" format provides the user
agent with the changes the state of the conference instance has
experimented since the last notification sent to the user agent.
Protect Your Project Zero Applications with OpenID
Access control-based security of application resources is one of the
core features of Project Zero. The OpenID Foundation describes OpenID
as an open, decentralized, free framework for user-centric digital
identity. OpenID takes advantage of already existing Internet technology
(URI, HTTP, SSL, Diffie-Hellman) and realizes that people are already
creating identities for themselves whether it be at their blog,
photostream, profile page, and so on. With OpenID you can easily
transform one of these existing URIs into an account you can use at
sites which support OpenID logins. Project Zero adopted the OpenID
technology as part of its security offering. In this article, the third
and final part of the series, you learn about Project Zero Security and
how to leverage OpenID authentication, define security rules for the
application, and extend a user registry... OpenID provides increased
flexibility for application deployment by enabling applications to
leverage third-party authentication providers for handling authentication.
Providers such as OpenID have become very common as more users want
a single user profile across multiple sites for blogs, wikis, and other
social networking activities. Additionally, many Web sites do not want
to maintain, or require users to continually provide, the same
profile-related information just to ensure that the user credentials
are valid. We hope this final article in the series has helped you learn
how to use the OpenID technology in the Project Zero platform to achieve
this decentralized authentication, and that the entire series has helped
you understand best practices for building the all-important security
features into your Zero applications. As a developer of fast-paced,
user-driven Web 2.0 applications, you know how vital security is to
both your customers and your business.
core features of Project Zero. The OpenID Foundation describes OpenID
as an open, decentralized, free framework for user-centric digital
identity. OpenID takes advantage of already existing Internet technology
(URI, HTTP, SSL, Diffie-Hellman) and realizes that people are already
creating identities for themselves whether it be at their blog,
photostream, profile page, and so on. With OpenID you can easily
transform one of these existing URIs into an account you can use at
sites which support OpenID logins. Project Zero adopted the OpenID
technology as part of its security offering. In this article, the third
and final part of the series, you learn about Project Zero Security and
how to leverage OpenID authentication, define security rules for the
application, and extend a user registry... OpenID provides increased
flexibility for application deployment by enabling applications to
leverage third-party authentication providers for handling authentication.
Providers such as OpenID have become very common as more users want
a single user profile across multiple sites for blogs, wikis, and other
social networking activities. Additionally, many Web sites do not want
to maintain, or require users to continually provide, the same
profile-related information just to ensure that the user credentials
are valid. We hope this final article in the series has helped you learn
how to use the OpenID technology in the Project Zero platform to achieve
this decentralized authentication, and that the entire series has helped
you understand best practices for building the all-important security
features into your Zero applications. As a developer of fast-paced,
user-driven Web 2.0 applications, you know how vital security is to
both your customers and your business.
Sunday, February 17, 2008
SourceForge: Office Binary (doc, xls, ppt) Translator to Open XML Project
"As promised last month, the binary documentation (.doc, .xls, .ppt)
is now live. In addition to this, the project to create an open source
translator (binary to Open XML) has now been formed on SourceForge,
and the development roadmap has been published. While the project is
still in its infancy, you can see what the planned project roadmap is,
as well as an early draft of a mapping table between the Word binary
format (.doc) and the Open XML format (.docx). The binary documentation
itself is also available; it's all covered under the Open Specification
Promise. Another great surprise in all of this is that we've made the
documentation for a few other supporting technologies available as it
may be of use to folks implementing the binary formats: (1) Windows
Compound Binary File Format Specification; (2) Windows Metafile Format
(.wmf) Specification; (3) Ink Serialized Format (ISF) Specification..."
From the Overview: "The main goal of the Office Binary (doc, xls, ppt)
Translator to Open XML project is to create software tools, plus
guidance, showing how a document written using the Binary Formats
(doc, xls, ppt) can be translated into the Office Open XML format. As
a result customers can use these tools to migrate from the binary formats
to Office Open XML Format thus enabling them to more easily access their
existing content in the new world of XML. The Translator will be
available under the open source Berkeley Software Distribution (BSD)
license, which allows that anyone can use the mapping, submit bugs and
feedback, or contribute to the project. On February 15th 2008, Microsoft
has made it even easier to get access to the binary formats documentation
from [the Microsoft Office Binary File Formats web site], and the binary
formats have also been made available under the Microsoft Open
Specification Promise. The Office Open XML file format has been approved
as an Ecma standard and is available [online]. We have chosen to use an
Open Source development model that allows developers from all around the
world to participate and contribute to the project. More Information See also the SourceForge Project: Click Here
is now live. In addition to this, the project to create an open source
translator (binary to Open XML) has now been formed on SourceForge,
and the development roadmap has been published. While the project is
still in its infancy, you can see what the planned project roadmap is,
as well as an early draft of a mapping table between the Word binary
format (.doc) and the Open XML format (.docx). The binary documentation
itself is also available; it's all covered under the Open Specification
Promise. Another great surprise in all of this is that we've made the
documentation for a few other supporting technologies available as it
may be of use to folks implementing the binary formats: (1) Windows
Compound Binary File Format Specification; (2) Windows Metafile Format
(.wmf) Specification; (3) Ink Serialized Format (ISF) Specification..."
From the Overview: "The main goal of the Office Binary (doc, xls, ppt)
Translator to Open XML project is to create software tools, plus
guidance, showing how a document written using the Binary Formats
(doc, xls, ppt) can be translated into the Office Open XML format. As
a result customers can use these tools to migrate from the binary formats
to Office Open XML Format thus enabling them to more easily access their
existing content in the new world of XML. The Translator will be
available under the open source Berkeley Software Distribution (BSD)
license, which allows that anyone can use the mapping, submit bugs and
feedback, or contribute to the project. On February 15th 2008, Microsoft
has made it even easier to get access to the binary formats documentation
from [the Microsoft Office Binary File Formats web site], and the binary
formats have also been made available under the Microsoft Open
Specification Promise. The Office Open XML file format has been approved
as an Ecma standard and is available [online]. We have chosen to use an
Open Source development model that allows developers from all around the
world to participate and contribute to the project. More Information See also the SourceForge Project: Click Here
OASIS Members Submit Charter for ebXML Core (ebCore) Technical Committee
OASIS announced the submission of a draft charter for a new ebXML Core
(ebCore) Technical Committee. The ebXML Core TC is to be the maintenance
group for ebXML TC specifications as these specifications are completed
or transitioned to the ebXML Core TC. The OASIS ebXML Joint Committee
is disbanding, so ebXML Core TC will take on the roles and the work of
the ebXML JC, and in addition will do maintenance on the standards that
have been produced by the ebXML TCs: ebXML Messaging, ebXML CPPA, ebXML
ebBP, ebXML IIC, and ebXML RegRep. Companies represented by the TC
proposers include Axway Software, The Boeing Company, British
Telecommunications plc, Fujitsu Limited, and Sonnenglanz Consulting.
The ebXML Core TC will provide the means to manage clarifications,
modifications, and enhancements for the specifications that ebXML TCs
have either completed and/or turned over as work in progress for
completion through the OASIS standards process. The ebXML Core TC may
issue errata for specifications that they maintain and may complete
reviews and changes required by editor's on committee drafts received
by the TC for completion. The ebXML Core TC may form subcommittees to
provide focus for specific specification tasks as they arise. The ebXML
Core TC may lead the formation of charters for new ebXML TCs for major
new versions of specifications. The TC may also produce new conformance
profiles and adjunct documents complementing existing specifications.
The ebXML Core TC will solicit new end user requirements as well as
implementation enhancements and change requests. The TC will also
explore synergies with UN/CEFACT, WS-* specifications and SOA best
practices. The ebXML Core TC may update schemas, examples,
specifications and other products of ebXML TC activities. More Information
(ebCore) Technical Committee. The ebXML Core TC is to be the maintenance
group for ebXML TC specifications as these specifications are completed
or transitioned to the ebXML Core TC. The OASIS ebXML Joint Committee
is disbanding, so ebXML Core TC will take on the roles and the work of
the ebXML JC, and in addition will do maintenance on the standards that
have been produced by the ebXML TCs: ebXML Messaging, ebXML CPPA, ebXML
ebBP, ebXML IIC, and ebXML RegRep. Companies represented by the TC
proposers include Axway Software, The Boeing Company, British
Telecommunications plc, Fujitsu Limited, and Sonnenglanz Consulting.
The ebXML Core TC will provide the means to manage clarifications,
modifications, and enhancements for the specifications that ebXML TCs
have either completed and/or turned over as work in progress for
completion through the OASIS standards process. The ebXML Core TC may
issue errata for specifications that they maintain and may complete
reviews and changes required by editor's on committee drafts received
by the TC for completion. The ebXML Core TC may form subcommittees to
provide focus for specific specification tasks as they arise. The ebXML
Core TC may lead the formation of charters for new ebXML TCs for major
new versions of specifications. The TC may also produce new conformance
profiles and adjunct documents complementing existing specifications.
The ebXML Core TC will solicit new end user requirements as well as
implementation enhancements and change requests. The TC will also
explore synergies with UN/CEFACT, WS-* specifications and SOA best
practices. The ebXML Core TC may update schemas, examples,
specifications and other products of ebXML TC activities. More Information
XML 1.0 (Fifth Edition)
The fifth edition of XML 1.0 is now a 'Proposed Edited Recommendation'
(PER). New editions do little more than incorporate errata, hardly
newsworthy. This one is different. Fifth Edition is now out for review.
The review period is long, lasting until 16-May-2008, because one of
the proposed changes is significant. Before the fifth edition, XML 1.0
was explicitly based on Unicode 2.0. As of the fifth edition, it is
based on Unicode 5.0.0 or later. This effectively allows not only
characters used today, but also characters that will be used tomorrow.
One of the real strengths of XML from the very beginning was that it
required processors to support Unicode. This made XML, and all XML
processors, international. But as Unicode has been extended to support
languages written in Cherokee, Ethiopic, Khmer, Mongolian, Canadian
Syllabics, and other scripts, XML 1.0's explicit use of Unicode 2.0 has
prevented it from growing as well. That's a problem that XML must fix
if it wants to continue to be regarded as a universal text format...
The fifth edition does not change the status of any existing XML 1.0
document with respect to well-formedness or validity. Nor does it
introduce any of the backwards-incompatible changes introduced in XML 1.1.
It isn't entirely without pain, unfortunately. Even if we imagine that
all parsers will be updated to reflect the fifth edition (and it's
possible to be optimistic on this point as it actually makes parsers
smaller and simpler) eventually, there will be some period of time in
which your (fourth edition) parser might reject my (fifth edition)
document. The XML Core WG is taking the position that the benefits of
extending XML 1.0 in this way outweigh the costs imposed by the change.
It remains to be seen if the community will agree. Bear in mind that
this sort of change isn't entirely unprecedented, we previously
decoupled 'xml:lang' attributes from the relevent RFCs and we tinkered
with the specific version of Unicode 3 referenced. That said, this is
still a much more substantial change. More Information See also the XML-DEV discussion thread: Click Here
(PER). New editions do little more than incorporate errata, hardly
newsworthy. This one is different. Fifth Edition is now out for review.
The review period is long, lasting until 16-May-2008, because one of
the proposed changes is significant. Before the fifth edition, XML 1.0
was explicitly based on Unicode 2.0. As of the fifth edition, it is
based on Unicode 5.0.0 or later. This effectively allows not only
characters used today, but also characters that will be used tomorrow.
One of the real strengths of XML from the very beginning was that it
required processors to support Unicode. This made XML, and all XML
processors, international. But as Unicode has been extended to support
languages written in Cherokee, Ethiopic, Khmer, Mongolian, Canadian
Syllabics, and other scripts, XML 1.0's explicit use of Unicode 2.0 has
prevented it from growing as well. That's a problem that XML must fix
if it wants to continue to be regarded as a universal text format...
The fifth edition does not change the status of any existing XML 1.0
document with respect to well-formedness or validity. Nor does it
introduce any of the backwards-incompatible changes introduced in XML 1.1.
It isn't entirely without pain, unfortunately. Even if we imagine that
all parsers will be updated to reflect the fifth edition (and it's
possible to be optimistic on this point as it actually makes parsers
smaller and simpler) eventually, there will be some period of time in
which your (fourth edition) parser might reject my (fifth edition)
document. The XML Core WG is taking the position that the benefits of
extending XML 1.0 in this way outweigh the costs imposed by the change.
It remains to be seen if the community will agree. Bear in mind that
this sort of change isn't entirely unprecedented, we previously
decoupled 'xml:lang' attributes from the relevent RFCs and we tinkered
with the specific version of Unicode 3 referenced. That said, this is
still a much more substantial change. More Information See also the XML-DEV discussion thread: Click Here
OASIS TC Publishes Code List Representation (Genericode) Version 1.0
G. Ken Holman announced that "Code List Representation (Genericode)
Version 1.0" (Committee Specification 01) has been published, and is
available online. Edited by Anthony B. Coates on behalf of the OASIS
Code List Representation TC, this document describes the OASIS Code
List Representation model and W3C XML Schema, known collectively as
'genericode'. Code lists, or enumerated values, have been with us since
long before computers. Most people would agree that the following is
a code list: {'SUN', 'MON', 'TUE', 'WED', 'THU', 'FRI', 'SAT'}. Code
lists should be well understood and easily dealt with by now.
Unfortunately, they are not. As is often the case, if you take a
fundamentally simple concept, you find that everyone professes to
understand it with complete clarity. When you look more closely, you
find that everybody has their own unique view of what the problem is
and how it should be solved. If code lists were really so simple and
obvious, there would already be a single, well-known and accepted way
of handling them in XML. There is no such agreed solution, though.
The problem is that while code lists are a well understood concept,
people don't actually agree exactly on what code lists are, and how
they should be used. The OASIS Code List Representation format,
'genericode', is a single model and XML format (with a W3C XML Schema)
that can encode a broad range of code list information. The XML format
is designed to support interchange or distribution of machine-readable
code list information between systems. Note that genericode is not
designed as a run-time format for accessing code list information, and
is not optimized for such usage. Rather, it is designed as an
interchange format that can be transformed into formats suitable for
run-time usage, or loaded into systems that perform run-time processing
using code list information. There are 3 kinds of genericode documents,
all supported by the one W3C XML Schema: (1) Column Set documents
(contain definitions of genericode columns or keys that can be imported
into code list documents or into other column set documents); (2) Code
List documents (contain metadata describing the code list as a whole,
as well as explicit code list data -- codes and associated values); (3)
Code List Set documents (contain references to particular versions of
code lists, and can also contain version-independent references to code
lists; a code list set document can be used to define a particular
configuration of versions of code lists that are used by a project,
application, standard, etc.). Work on the corresponding CVA formats is
still underway. More Information
Version 1.0" (Committee Specification 01) has been published, and is
available online. Edited by Anthony B. Coates on behalf of the OASIS
Code List Representation TC, this document describes the OASIS Code
List Representation model and W3C XML Schema, known collectively as
'genericode'. Code lists, or enumerated values, have been with us since
long before computers. Most people would agree that the following is
a code list: {'SUN', 'MON', 'TUE', 'WED', 'THU', 'FRI', 'SAT'}. Code
lists should be well understood and easily dealt with by now.
Unfortunately, they are not. As is often the case, if you take a
fundamentally simple concept, you find that everyone professes to
understand it with complete clarity. When you look more closely, you
find that everybody has their own unique view of what the problem is
and how it should be solved. If code lists were really so simple and
obvious, there would already be a single, well-known and accepted way
of handling them in XML. There is no such agreed solution, though.
The problem is that while code lists are a well understood concept,
people don't actually agree exactly on what code lists are, and how
they should be used. The OASIS Code List Representation format,
'genericode', is a single model and XML format (with a W3C XML Schema)
that can encode a broad range of code list information. The XML format
is designed to support interchange or distribution of machine-readable
code list information between systems. Note that genericode is not
designed as a run-time format for accessing code list information, and
is not optimized for such usage. Rather, it is designed as an
interchange format that can be transformed into formats suitable for
run-time usage, or loaded into systems that perform run-time processing
using code list information. There are 3 kinds of genericode documents,
all supported by the one W3C XML Schema: (1) Column Set documents
(contain definitions of genericode columns or keys that can be imported
into code list documents or into other column set documents); (2) Code
List documents (contain metadata describing the code list as a whole,
as well as explicit code list data -- codes and associated values); (3)
Code List Set documents (contain references to particular versions of
code lists, and can also contain version-independent references to code
lists; a code list set document can be used to define a particular
configuration of versions of code lists that are used by a project,
application, standard, etc.). Work on the corresponding CVA formats is
still underway. More Information
W3C Last Call Working Draft: CSS Namespaces Module
W3C announced the release of an updated, Last Call Working Draft for
the "CSS Namespaces Module" specification, updating the previous WD
published 2006-08-28. The previous draft was edited by Peter Linss and
Chris Lilley. The deadline for comments is 7-March-2008. This CSS
Namespaces Module defines syntax for using namespaces in CSS. It defines
the '@namespace' rule for declaring a default namespace and for binding
namespaces to namespace prefixes. It also defines a syntax for using
those prefixes to represent namespace-qualified names. It does not
define where such names are valid or what they mean: that depends on
their context and is defined by a host language, such as Selectors,
that references the syntax defined in the CSS Namespaces module. Note
that a CSS client that does not support this module will, if it properly
conforms to CSS's forward-compatible parsing rules, ignore all
'@namespace' rules, as well as all style rules that make use of namespace
qualified names. The syntax of delimiting namespace prefixes in CSS was
deliberately chosen so that these CSS clients would ignore the style
rules rather than possibly match them incorrectly. A document or
implementation cannot conform to CSS Namespaces alone, but can claim
conformance to CSS Namespaces if it satisfies the conformance requirements
in this specification when implementing CSS or another host language that
normatively references this specification. Conformance to CSS Namespaces
is defined for two classes: (1) style sheet: a CSS style sheet or a
complete unit of another host language that normatively references CSS
Namespaces; (2) interpreter: someone or something that interprets the
semantics of a style sheet, where CSS user agents fall under this
category. CSS is the Web's primary style sheet language for specifying
the rendering of text documents, in particular those expressed in HTML
and XML-based formats. It can also be used to specify portions of the
rendering of certain non-text formats, such as SMIL (multimedia) and SVG
(vector graphics). The model of text-flow and the set of properties of
CSS are also shared with XSL, W3C's style language for complex formatting
of XML-based document formats, though XSL is developed by a separate WG.
In addition to visual output (screen, print), CSS also contains styling
properties for speech output. The CSS WG develops and maintains the CSS
language and related technologies. CSS allows both authors and readers
to specify the display or other rendering of documents, such as those in
HTML or SVG. CSS has several levels, from simple (level 1) to complex
(level 3) and several 'profiles,' which describe how CSS applies on
different media (TV, handheld, etc.). Level 1 is a Recommendation, level
2 is in maintenance, level 3 is currently being developed. More Information
the "CSS Namespaces Module" specification, updating the previous WD
published 2006-08-28. The previous draft was edited by Peter Linss and
Chris Lilley. The deadline for comments is 7-March-2008. This CSS
Namespaces Module defines syntax for using namespaces in CSS. It defines
the '@namespace' rule for declaring a default namespace and for binding
namespaces to namespace prefixes. It also defines a syntax for using
those prefixes to represent namespace-qualified names. It does not
define where such names are valid or what they mean: that depends on
their context and is defined by a host language, such as Selectors,
that references the syntax defined in the CSS Namespaces module. Note
that a CSS client that does not support this module will, if it properly
conforms to CSS's forward-compatible parsing rules, ignore all
'@namespace' rules, as well as all style rules that make use of namespace
qualified names. The syntax of delimiting namespace prefixes in CSS was
deliberately chosen so that these CSS clients would ignore the style
rules rather than possibly match them incorrectly. A document or
implementation cannot conform to CSS Namespaces alone, but can claim
conformance to CSS Namespaces if it satisfies the conformance requirements
in this specification when implementing CSS or another host language that
normatively references this specification. Conformance to CSS Namespaces
is defined for two classes: (1) style sheet: a CSS style sheet or a
complete unit of another host language that normatively references CSS
Namespaces; (2) interpreter: someone or something that interprets the
semantics of a style sheet, where CSS user agents fall under this
category. CSS is the Web's primary style sheet language for specifying
the rendering of text documents, in particular those expressed in HTML
and XML-based formats. It can also be used to specify portions of the
rendering of certain non-text formats, such as SMIL (multimedia) and SVG
(vector graphics). The model of text-flow and the set of properties of
CSS are also shared with XSL, W3C's style language for complex formatting
of XML-based document formats, though XSL is developed by a separate WG.
In addition to visual output (screen, print), CSS also contains styling
properties for speech output. The CSS WG develops and maintains the CSS
language and related technologies. CSS allows both authors and readers
to specify the display or other rendering of documents, such as those in
HTML or SVG. CSS has several levels, from simple (level 1) to complex
(level 3) and several 'profiles,' which describe how CSS applies on
different media (TV, handheld, etc.). Level 1 is a Recommendation, level
2 is in maintenance, level 3 is currently being developed. More Information
SEC Financial Explorer Supports XBRL Interactive Data
The U.S. Securities and Exchange Commission (SEC) has announced the
launch of the "Financial Explorer" on the SEC Web site to help
investors quickly and easily analyze the financial results of public
companies. XBRL is a member of the family of languages based on XML
(Extensible Markup Language), which is a standard for the electronic
exchange of data between businesses and on the internet. Under XML,
identifying tags are applied to items of data so that they can be
processed efficiently by computer software. Financial Explorer paints
the picture of corporate financial performance with diagrams and charts,
using financial information provided to the SEC as "interactive data"
in Extensible Business Reporting Language (XBRL). At the click of a
mouse, Financial Explorer lets investors automatically generate
financial ratios, graphs, and charts depicting important information
from financial statements. Information including earnings, expenses,
cash flows, assets, and liabilities can be analyzed and compared across
competing public companies. The software takes the work out of
manipulating the data by entirely eliminating tasks such as copying and
pasting rows of revenues and expenses into a spreadsheet. That frees
investors to focus on their investments' financial results through
visual representations that make the numbers easier to understand.
Financial Explorer is open source software, meaning that its source
code is free to the public, and technology and financial experts can
update and enhance the software. As interactive data becomes more
commonplace, investors, analysts, and others working in the financial
industry may develop hundreds of Web-based applications that help
investors garner insights about financial results through creative
ways of analyzing and presenting the information. In addition to
Financial Explorer, the SEC currently offers investors two other
online viewers -- the Executive Compensation viewer and the Interactive
Financial Report viewer, also available at online. The Executive
Compensation viewer enables investors to instantly compare what 500
of the largest U.S. companies are paying their top executives. The
Interactive Financial Report viewer also helps investors gather,
analyze, and compare key financial disclosures filed voluntarily by
public companies using XBRL. To date, there have been 307 such filings
from 74 companies. Under the SEC's interactive data filing program,
companies may continue to file XBRL data voluntarily, pending
anticipated Commission rulemaking. More Information See also the Financial Explorer web site: Click Here
launch of the "Financial Explorer" on the SEC Web site to help
investors quickly and easily analyze the financial results of public
companies. XBRL is a member of the family of languages based on XML
(Extensible Markup Language), which is a standard for the electronic
exchange of data between businesses and on the internet. Under XML,
identifying tags are applied to items of data so that they can be
processed efficiently by computer software. Financial Explorer paints
the picture of corporate financial performance with diagrams and charts,
using financial information provided to the SEC as "interactive data"
in Extensible Business Reporting Language (XBRL). At the click of a
mouse, Financial Explorer lets investors automatically generate
financial ratios, graphs, and charts depicting important information
from financial statements. Information including earnings, expenses,
cash flows, assets, and liabilities can be analyzed and compared across
competing public companies. The software takes the work out of
manipulating the data by entirely eliminating tasks such as copying and
pasting rows of revenues and expenses into a spreadsheet. That frees
investors to focus on their investments' financial results through
visual representations that make the numbers easier to understand.
Financial Explorer is open source software, meaning that its source
code is free to the public, and technology and financial experts can
update and enhance the software. As interactive data becomes more
commonplace, investors, analysts, and others working in the financial
industry may develop hundreds of Web-based applications that help
investors garner insights about financial results through creative
ways of analyzing and presenting the information. In addition to
Financial Explorer, the SEC currently offers investors two other
online viewers -- the Executive Compensation viewer and the Interactive
Financial Report viewer, also available at online. The Executive
Compensation viewer enables investors to instantly compare what 500
of the largest U.S. companies are paying their top executives. The
Interactive Financial Report viewer also helps investors gather,
analyze, and compare key financial disclosures filed voluntarily by
public companies using XBRL. To date, there have been 307 such filings
from 74 companies. Under the SEC's interactive data filing program,
companies may continue to file XBRL data voluntarily, pending
anticipated Commission rulemaking. More Information See also the Financial Explorer web site: Click Here
WLS 10.3 Tech Preview Supports Service Component Architecture (SCA)
WebLogic 10.3 Tech preview now supports Service Component Architecture
(SCA) runtime. The SCA specification has two main parts: implementation
of service components (which can be done in any language) and the
assembly model which is the linking of components through wiring (which
is done through XML files). Every component technology (Spring, POJO,
EJB etc) that wants to participate in the SCA framework should support
SCA metadata. The SCA specification defines language bindings for each
of the technologies. In my opinion, SCA is the next evolution of building
interoperable distributed systems. The claim to fame for SOAP based web
services is that it provided a programming model where clients do not
care as to which programming language the service is implemented. The
client can be written in any language that has a SOAP binding. The only
restriction on the client is that it has to use the SOAP API. Thus by
service enabling your existing business services and modifying your
legacy clients to speak SOAP, web services have made enterprise
integration easier compared to yester years. Now SCA takes this
interoperability to the next level, where now your clients can stay as
is and do not have to use the same transport as the service. All the
client knows is that it is a remotable service. Let us say you have a
Java client that was talking to an EJB. Now this EJB has been converted
into a web service. In this case, the Java client does not have to
change to use SOAP API. Instead it can still use its EJB client code
because the web service (which is an SCA component) can be decorated
with an EJB binding. Thus the service can be implemented in one technology
such as Spring, POJO, EJB, web service or BPEL and it can be decorated
with a different binding (Spring, POJO, EJB, web services etc) to support
different clients. By including the SCA runtime on WLS, customers can
take advantage of the RASP functionality provided by WLS for the deployed
SCA components. The infrastructural capabilities such as security,
transactions, reliable messaging that are to be handled declaratively
through policies under the SCA specification can all be provided by WLS. More Information
(SCA) runtime. The SCA specification has two main parts: implementation
of service components (which can be done in any language) and the
assembly model which is the linking of components through wiring (which
is done through XML files). Every component technology (Spring, POJO,
EJB etc) that wants to participate in the SCA framework should support
SCA metadata. The SCA specification defines language bindings for each
of the technologies. In my opinion, SCA is the next evolution of building
interoperable distributed systems. The claim to fame for SOAP based web
services is that it provided a programming model where clients do not
care as to which programming language the service is implemented. The
client can be written in any language that has a SOAP binding. The only
restriction on the client is that it has to use the SOAP API. Thus by
service enabling your existing business services and modifying your
legacy clients to speak SOAP, web services have made enterprise
integration easier compared to yester years. Now SCA takes this
interoperability to the next level, where now your clients can stay as
is and do not have to use the same transport as the service. All the
client knows is that it is a remotable service. Let us say you have a
Java client that was talking to an EJB. Now this EJB has been converted
into a web service. In this case, the Java client does not have to
change to use SOAP API. Instead it can still use its EJB client code
because the web service (which is an SCA component) can be decorated
with an EJB binding. Thus the service can be implemented in one technology
such as Spring, POJO, EJB, web service or BPEL and it can be decorated
with a different binding (Spring, POJO, EJB, web services etc) to support
different clients. By including the SCA runtime on WLS, customers can
take advantage of the RASP functionality provided by WLS for the deployed
SCA components. The infrastructural capabilities such as security,
transactions, reliable messaging that are to be handled declaratively
through policies under the SCA specification can all be provided by WLS. More Information
Friday, February 15, 2008
W3C Publishes Best Practices for XML Internationalization
W3C's Internationalization Tag Set (ITS) Working Group has published a
Group Note for "Best Practices for XML Internationalization." The
specification provides a set of guidelines for developing XML documents
and schemas that are internationalized properly. Following the best
practices describes here allow both the developer of XML applications,
as well as the author of XML content to create material in different
languages. This document and "Internationalization Tag Set (ITS)
Version 1.0" implement requirements formulated in "Internationalization
and Localization Markup Requirements." This note is intended to
complement the W3C ITS Recommendation, since not all
internationalization-related issues can be resolved by the special
markup described in ITS. The best practices in this document therefore
go beyond application of ITS markup to address a number of problems
that can be avoided by correctly designing the XML format, and by
applying a additional guidelines when developing content. Guidelines
for designers and developers of XML applications are presented in
three sections. Section 2 "When Designing an XML Application" provides
a list of some of the important design choices you should make in
order to ensure the internationalization of your format. Section 4
"Generic Techniques" provides additional generic techniques such as
writing ITS rules or adding an attribute to a schema; such techniques
apply to many of the best practices. Section 5 "ITS Applied to
Existing Formats" provides a set of concrete examples on how to apply
ITS to existing XML based formats; this section illustrates many of
the guidelines in this document. Guidelines for users and authors of
XML content are outlined in other document sections. Section 3 "When
Authoring XML Content" provides a number of guidelines on how to create
content with internationalization in mind. Many of these best practices
are relevant regardless of whether or not your XML format was developed
especially for internationalization. Section 4.1 "Writing ITS Rules"
provides practical guidelines on how to write ITS rules. Such
techniques may be useful when applying some of the more advanced
authoring best practices. More Information
Group Note for "Best Practices for XML Internationalization." The
specification provides a set of guidelines for developing XML documents
and schemas that are internationalized properly. Following the best
practices describes here allow both the developer of XML applications,
as well as the author of XML content to create material in different
languages. This document and "Internationalization Tag Set (ITS)
Version 1.0" implement requirements formulated in "Internationalization
and Localization Markup Requirements." This note is intended to
complement the W3C ITS Recommendation, since not all
internationalization-related issues can be resolved by the special
markup described in ITS. The best practices in this document therefore
go beyond application of ITS markup to address a number of problems
that can be avoided by correctly designing the XML format, and by
applying a additional guidelines when developing content. Guidelines
for designers and developers of XML applications are presented in
three sections. Section 2 "When Designing an XML Application" provides
a list of some of the important design choices you should make in
order to ensure the internationalization of your format. Section 4
"Generic Techniques" provides additional generic techniques such as
writing ITS rules or adding an attribute to a schema; such techniques
apply to many of the best practices. Section 5 "ITS Applied to
Existing Formats" provides a set of concrete examples on how to apply
ITS to existing XML based formats; this section illustrates many of
the guidelines in this document. Guidelines for users and authors of
XML content are outlined in other document sections. Section 3 "When
Authoring XML Content" provides a number of guidelines on how to create
content with internationalization in mind. Many of these best practices
are relevant regardless of whether or not your XML format was developed
especially for internationalization. Section 4.1 "Writing ITS Rules"
provides practical guidelines on how to write ITS rules. Such
techniques may be useful when applying some of the more advanced
authoring best practices. More Information
Google Code Project Provides an Enterprise Java XACML Implementation
The 'enterprise-java-xacml' Google Code Project provides a high
performance XACML 2.0 implementation that can used in the enterprise
environment. A first release has been announced; the software is
made available under the Apache License 2.0. Enterprise Java XACML
intends to fully implement OASIS XACML 2.0 and will support XACML
3.0 in the future. It is a totally independent implementation. It
fully implements XACML 2.0 core standard and has passed all
conformance tests. It provides PDP that can accept XACML requests
and returns XACML responses. The software is said to offer a highly
effective target indexing mechanism that greatly speeds up policy
searching: completely cached decisions that can speed up the
evaluation, and completely cached policies that can speed up the
evaluation. It supports a plugable data store mechanism: users can
implement their own data store by implementing only a few interfaces;
a file data store implementation is provided. It features a plugable
context factory: users can implement their own context factory that
wrap request/response in a specific format, and a default
implementation is supplied. A plugable logger mechanism means users
can implement their own logger mechanism: "I've provided 2 types of
logger, one is log4j, the other is a default logger; if log4j
conflicts with user's system, they may want to use this default one."
The tool supports an extensible XACML function registering mechanism;
users can write their own functions and register them to PDP and then
use in policies. The extensible attribute retriever mechanism means
that users can write their own attribute retriever to retrieve
attributes from external systems. It provides simple PAP APIs that
can be used to produce XACML policy files; users who want write an
XACML policy administrative UI can also rely on these APIs. Both
XACML APIs and an application framework are supported, which means
users can incorporate this implementation by calling XACML APIs from
their own applications. The implementation also provides a standalone
application framework that users can start and directly send XACML
request to it for evaluation. The software is distributed with unit
tests and conformance tests against XACML 2.0. More Information
performance XACML 2.0 implementation that can used in the enterprise
environment. A first release has been announced; the software is
made available under the Apache License 2.0. Enterprise Java XACML
intends to fully implement OASIS XACML 2.0 and will support XACML
3.0 in the future. It is a totally independent implementation. It
fully implements XACML 2.0 core standard and has passed all
conformance tests. It provides PDP that can accept XACML requests
and returns XACML responses. The software is said to offer a highly
effective target indexing mechanism that greatly speeds up policy
searching: completely cached decisions that can speed up the
evaluation, and completely cached policies that can speed up the
evaluation. It supports a plugable data store mechanism: users can
implement their own data store by implementing only a few interfaces;
a file data store implementation is provided. It features a plugable
context factory: users can implement their own context factory that
wrap request/response in a specific format, and a default
implementation is supplied. A plugable logger mechanism means users
can implement their own logger mechanism: "I've provided 2 types of
logger, one is log4j, the other is a default logger; if log4j
conflicts with user's system, they may want to use this default one."
The tool supports an extensible XACML function registering mechanism;
users can write their own functions and register them to PDP and then
use in policies. The extensible attribute retriever mechanism means
that users can write their own attribute retriever to retrieve
attributes from external systems. It provides simple PAP APIs that
can be used to produce XACML policy files; users who want write an
XACML policy administrative UI can also rely on these APIs. Both
XACML APIs and an application framework are supported, which means
users can incorporate this implementation by calling XACML APIs from
their own applications. The implementation also provides a standalone
application framework that users can start and directly send XACML
request to it for evaluation. The software is distributed with unit
tests and conformance tests against XACML 2.0. More Information
Yet Another Computer Language
"...Microsoft is designing yet another computer language... it's a
declarative language [but] 'Declarative' is an awfully broad term, with
multiple meanings. Standard ML is considered declarative, and so are
its derivatives OCAML and F#. Prolog and rule-based AI systems are
considered declarative. You declare the rules: the logic engine decides
how to run them. SQL queries are declarative: you describe the data you
want to see, and the query optimizer figures out how to get it out of
the database. Haskell is considered declarative as well as functional,
not to mention that it has monads... XAML is a declarative language for
the domain of graphics. It was designed as an extension of XML. It's
such an expressive language that Charlie Petzold, arguably one of XAML's
most vocal proponents, built himself a alternative to Microsoft's XAMLPad
called XAML Cruncher, so that he could 'interactively type XAML code and
see the object it creates.' In Visual Studio 2008, Microsoft included a
bidirectional, split-screen XAML designer, so that you can create XAML
by dragging and dropping objects and by typing XAML code, with the ability
to freely switch back and forth between the two methods. I freely admit
to needing these tools; I can almost never write XAML that will display
correctly on the first try. Watching the Connected Systems Division (CSD)
at Microsoft over the years, it has been clear that they have been on a
code-reduction path. Why? SOAP was invented by Don Box and others to be
an XML-based lingua franca for communication among disparate computer
applications and systems. The functional deficiencies of SOAP were
addressed by the WS-* series of standards, to give it security,
authentication, reliability, and so on. All of those standards made it
harder to write conformant client and server code, raising the complexity
by orders of magnitude..." From Microsoft's "XAML Overview" document:
"XAML simplifies creating a UI for the .NET Framework programming model.
You can create visible UI elements in the declarative XAML markup, and
then separate the UI definition from the run-time logic by using
code-behind files, joined to the markup through partial class definitions.
The ability to mix code with markup in XAML is important because XML by
itself is declarative, and does not really suggest a model for flow
control. An XML based declarative language is very intuitive for creating
interfaces ranging from prototype to production, especially for people
with a background in web design and technologies. Unlike most other
markup languages, XAML directly represents the instantiation of managed
objects. This general design principle enables simplified code and
debugging access for objects that are created in XAML." More Information See also the XAML Overview: Click Here
declarative language [but] 'Declarative' is an awfully broad term, with
multiple meanings. Standard ML is considered declarative, and so are
its derivatives OCAML and F#. Prolog and rule-based AI systems are
considered declarative. You declare the rules: the logic engine decides
how to run them. SQL queries are declarative: you describe the data you
want to see, and the query optimizer figures out how to get it out of
the database. Haskell is considered declarative as well as functional,
not to mention that it has monads... XAML is a declarative language for
the domain of graphics. It was designed as an extension of XML. It's
such an expressive language that Charlie Petzold, arguably one of XAML's
most vocal proponents, built himself a alternative to Microsoft's XAMLPad
called XAML Cruncher, so that he could 'interactively type XAML code and
see the object it creates.' In Visual Studio 2008, Microsoft included a
bidirectional, split-screen XAML designer, so that you can create XAML
by dragging and dropping objects and by typing XAML code, with the ability
to freely switch back and forth between the two methods. I freely admit
to needing these tools; I can almost never write XAML that will display
correctly on the first try. Watching the Connected Systems Division (CSD)
at Microsoft over the years, it has been clear that they have been on a
code-reduction path. Why? SOAP was invented by Don Box and others to be
an XML-based lingua franca for communication among disparate computer
applications and systems. The functional deficiencies of SOAP were
addressed by the WS-* series of standards, to give it security,
authentication, reliability, and so on. All of those standards made it
harder to write conformant client and server code, raising the complexity
by orders of magnitude..." From Microsoft's "XAML Overview" document:
"XAML simplifies creating a UI for the .NET Framework programming model.
You can create visible UI elements in the declarative XAML markup, and
then separate the UI definition from the run-time logic by using
code-behind files, joined to the markup through partial class definitions.
The ability to mix code with markup in XAML is important because XML by
itself is declarative, and does not really suggest a model for flow
control. An XML based declarative language is very intuitive for creating
interfaces ranging from prototype to production, especially for people
with a background in web design and technologies. Unlike most other
markup languages, XAML directly represents the instantiation of managed
objects. This general design principle enables simplified code and
debugging access for objects that are created in XAML." More Information See also the XAML Overview: Click Here
Layer 7 Announces XML Firewall and XML Networking Gateway Products
Layer 7 Technologies has announced its XML Firewall and XML Networking
Gateway software products support the Solaris 10 Operating System (OS)
running on SPARC platforms from Sun Microsystems. Layer 7 is the only
XML security and networking vendor to offer server software for Solaris
10 OS running on SPARC and x86 platforms through an upgradeable family
of XML appliances for Service Oriented Architectures (SOA) and Web 2.0
applications. For customers with processor-intensive SOA and Web 2.0
applications, Layer 7 introduced support for Solaris 10 OS on SPARC to
further the scalability, density and performance offerings by Sun's
SPARC Enterprise Servers. Many of Layer 7's customers use SPARC-based
platforms for high-volume data center applications making SPARC
technology their first choice for SOA and XML applications. The
SecureSpan XML Firewall combines the capabilities of the SecureSpan XML
Accelerator and Data Screen with advanced identity and message level
security to address the broadest range of behind the firewall, portal
and B2B SOA security challenges. The SecureSpan XML Firewall includes
support for all leading directory, identity, access control, Single
Sign-On (SSO) and Federation services. This provides SOA and security
architects unparalleled flexibility in defining and enforcing
identity-driven SOA security policies leveraging SSO session cookies,
Kerberos tickets, SAML assertions and PKI. The SecureSpan XML Firewall
also provides architects with advanced policy controls for specifying
message and element security rules including the ability to branch
policy based on any message context. Key storage, encryption and signing
operations can be handled in FIPS 140-2 certified acceleration hardware
onboard the appliance or centrally through Safenet's Luna HSM. The
SecureSpan XML Firewall has demonstrated compliance with all major WS*
and WS-I security protocols including WS-Security, WS-SecureConversation,
WS-SecurityPolicy, WS-Trust, WS-Secure Exchange, WS-Policy and WS-I
Basic Security Profile. The SecureSpan Firewall also supports SAML 1.1
and 2.0 both in sender vouches and holder of key models.
Gateway software products support the Solaris 10 Operating System (OS)
running on SPARC platforms from Sun Microsystems. Layer 7 is the only
XML security and networking vendor to offer server software for Solaris
10 OS running on SPARC and x86 platforms through an upgradeable family
of XML appliances for Service Oriented Architectures (SOA) and Web 2.0
applications. For customers with processor-intensive SOA and Web 2.0
applications, Layer 7 introduced support for Solaris 10 OS on SPARC to
further the scalability, density and performance offerings by Sun's
SPARC Enterprise Servers. Many of Layer 7's customers use SPARC-based
platforms for high-volume data center applications making SPARC
technology their first choice for SOA and XML applications. The
SecureSpan XML Firewall combines the capabilities of the SecureSpan XML
Accelerator and Data Screen with advanced identity and message level
security to address the broadest range of behind the firewall, portal
and B2B SOA security challenges. The SecureSpan XML Firewall includes
support for all leading directory, identity, access control, Single
Sign-On (SSO) and Federation services. This provides SOA and security
architects unparalleled flexibility in defining and enforcing
identity-driven SOA security policies leveraging SSO session cookies,
Kerberos tickets, SAML assertions and PKI. The SecureSpan XML Firewall
also provides architects with advanced policy controls for specifying
message and element security rules including the ability to branch
policy based on any message context. Key storage, encryption and signing
operations can be handled in FIPS 140-2 certified acceleration hardware
onboard the appliance or centrally through Safenet's Luna HSM. The
SecureSpan XML Firewall has demonstrated compliance with all major WS*
and WS-I security protocols including WS-Security, WS-SecureConversation,
WS-SecurityPolicy, WS-Trust, WS-Secure Exchange, WS-Policy and WS-I
Basic Security Profile. The SecureSpan Firewall also supports SAML 1.1
and 2.0 both in sender vouches and holder of key models.
XML at 10
Ten years ago today XML was born. That's when it was first published as
a Recommendation. XML goes back a little further than that, it
gestated, to stick to the metaphor, for almost two years at the W3C:
Dan Connolly announced the creation of the SGML Working Group mailing
list on 28-August-1996. It predates even that, of course, in the vision
of Yuri Rubinsky, Jon Bosak, and many others who imagined bringing the
full richness of generalized markup vocabularies to the then nascent
World Wide Web. My personal, professional career goes back to the fall
of 1993, so I came onto the scene only late in the development of 'SGML
on the Web' as an idea. It's earliest history is lost in the blur of
fear, excitement, and delight that I felt as I was thrust by circumstance
into the SGML community. I joined O'Reilly on the very first day of an
unprecedented two-week period during which the production department,
the folks who actually turn finished manuscripts into books, was closed.
The department was undergoing a two-week training period during which
they would learn SGML and, henceforth, all books would be done in SGML.
The day was a Monday in November, 1993; I know this for sure because I
still have the T-Shirt... Despite an inauspicious start, I have
essentially made my career out of it. I learned SGML at O'Reilly and
began working on DocBook, I worked in SGML professional services at
Arbortext, and I joined Sun to work in the XML Technology Center. XML
has been good to me. Things have not turned out as planned. The economic
forces that took over when the web became 'the next big thing' are
more interested in pixel-perfect rendering, animation, entertainment,
and advertising than in richly structured technical content. HTML 5
may be the last nail in the 'SGML on the Web' coffin, but few would
deny that XML has been a huge success. [Note: The DocBook Version 5.0
release is a complete rewrite of DocBook in RELAX NG. The intent of
this rewrite is to produce a schema that is true to the spirit of
DocBook while simultaneously removing inconsistencies that have arisen
as a natural consequence of DocBook's long, slow evolution. The
OASIS Technical Committee has taken this opportunity to simplify a
number of content models and tighten constraints where RELAX NG makes
that possible.]
a Recommendation. XML goes back a little further than that, it
gestated, to stick to the metaphor, for almost two years at the W3C:
Dan Connolly announced the creation of the SGML Working Group mailing
list on 28-August-1996. It predates even that, of course, in the vision
of Yuri Rubinsky, Jon Bosak, and many others who imagined bringing the
full richness of generalized markup vocabularies to the then nascent
World Wide Web. My personal, professional career goes back to the fall
of 1993, so I came onto the scene only late in the development of 'SGML
on the Web' as an idea. It's earliest history is lost in the blur of
fear, excitement, and delight that I felt as I was thrust by circumstance
into the SGML community. I joined O'Reilly on the very first day of an
unprecedented two-week period during which the production department,
the folks who actually turn finished manuscripts into books, was closed.
The department was undergoing a two-week training period during which
they would learn SGML and, henceforth, all books would be done in SGML.
The day was a Monday in November, 1993; I know this for sure because I
still have the T-Shirt... Despite an inauspicious start, I have
essentially made my career out of it. I learned SGML at O'Reilly and
began working on DocBook, I worked in SGML professional services at
Arbortext, and I joined Sun to work in the XML Technology Center. XML
has been good to me. Things have not turned out as planned. The economic
forces that took over when the web became 'the next big thing' are
more interested in pixel-perfect rendering, animation, entertainment,
and advertising than in richly structured technical content. HTML 5
may be the last nail in the 'SGML on the Web' coffin, but few would
deny that XML has been a huge success. [Note: The DocBook Version 5.0
release is a complete rewrite of DocBook in RELAX NG. The intent of
this rewrite is to produce a schema that is true to the spirit of
DocBook while simultaneously removing inconsistencies that have arisen
as a natural consequence of DocBook's long, slow evolution. The
OASIS Technical Committee has taken this opportunity to simplify a
number of content models and tighten constraints where RELAX NG makes
that possible.]
Subscribe to:
Posts (Atom)