W3C has issued a call for implementations in connection with the
publication of "XQuery Update Facility 1.0" as a Candidate Recommendation.
This specification defines an update facility that extends the XML Query
language, XQuery. W3C XQuery is "a standardized language for combining
documents, databases, Web pages and almost anything else. It is very
widely implemented. It is powerful and easy to learn. XQuery is replacing
proprietary middleware languages and Web Application development languages.
XQuery is replacing complex Java or C++ programs with a few lines of code.
XQuery is simpler to work with and easier to maintain than many other
alternatives." The XQuery Update Facility provides expressions that
can be used to make persistent changes to instances of the XQuery 1.0
and XPath 2.0 Data Model. Specifically, the XQuery Update Facility 1.0
provides facilities to perform any or all of the following operations
on an XDM instance: Insertion of a node; Deletion of a node; Modification
of a node by changing some of its properties while preserving its node
identity; Creation of a modified copy of a node with a new node identity.
The basic building block of XQuery is the expression. XQuery 1.0 provides
several kinds of expressions that can be composed with each other in
arbitrary ways. An XQuery 1.0 expression takes zero or more XDM instances
as input and returns an XDM instance as a result. In XQuery 1.0, an
expression never modifies the state of an existing node; however,
constructor expressions create new nodes with new node identities. XQuery
Update Facility 1.0 introduces a new category of expression called an
updating expression, which can potentially modify the state of an existing
node... The XML Query Working Group intends to submit this document for
consideration as a W3C Proposed Recommendation as soon as the following
conditions are met: (1) A test suite is available that tests each
identified XQuery Update Facility feature, both required and optional.
(2) 'Minimal Conformance' to this specification has been demonstrated by
at least two distinct implementations, at least one of which uses the
XQuery human-readable syntax defined in this specification. (3) The
Working Group has responded formally to all issues raised during the
CR period against this document. The document will remain a Candidate
Recommendation until at least 20-June-2008.

A Working Draft Version 01 specification for a "SAML V2.0 Metadata
Interoperability Profile" has been submitted to the OASIS Security
Services (SAML) TC. "This profile describes a set of rules for SAML
metadata producers and consumers to follow such that federated
relationships can be interoperably provisioned, and controlled at
runtime in a secure, understandable, and self-contained fashion. The
SAML V2.0 metadata specification ("Metadata for the OASIS Security
Assertion Markup Language V2.0") defines an XML schema and a set of
basic processing rules intended to facilitate the use of SAML profiles,
and generally any profile or specification involving SAML. Practical
experience has shown that the most complex aspects of implementing
most SAML profiles, and obtaining interoperability between such
implementations, are in the areas of provisioning federated relationships
between deployments, and establishing the validity of cryptographic
signatures and handshakes. Because the metadata specification was
largely intended to solve those exact problems, additional profiling
is needed to improve and clarify the use of metadata in addressing
those aspects of deployment. This profile is the product of the
implementation experience of several SAML solution providers and has
been widely deployed and successfully used in furtherance of the goal
of scaling deployment beyond small numbers into the hundreds and
thousands of sites, without sacrificing security. Experience has shown
that the most frustrating part of using SAML (and many similar
technologies) is that products approach the use of cryptography and
trust in wildly inconsistent ways, and often the libraries that such
products depend on do the same in their own domains. Key management
is hard, and often relies on complicated tools with cryptic output.
Standards only help insofar as they can be understood and widely
implemented; this has generally not occurred above a basic level of
cryptographic correctness. A formal PKI is a tremendously complex,
and some would say intractable, goal; it could be argued that SAML
itself is a reaction to this. Often, the security of deployments
is based on a presumption that required practices like revocation
checking are being performed, when in fact they are not. The purpose
of this profile is to guarantee that in a correct implementation,
all security considerations not deriving from the particular
cryptography used (i.e. algorithm strength, key sizes) can be isolated
to metadata exchange and acceptance, and not affect the runtime
processing of messages.

A revised version of the "SAML V2.0 Information Card Token Profile" has
been contributed to the OASIS SAML TC as Working Draft Version 02. This
Draft version 02 incorporates feedback, refines the Recipient/Audience
rules, adds a signing requirement, and enumerates assertion validation
processing rules. "This profile describes a set of rules for identity
providers and relying parties to follow when using SAML V2.0 assertions
as managed information card security tokens, so that interoperability
and security is achieved commensurate with other SAML authentication
profiles... Microsoft has defined a set of profiles for acquring and
delivering security tokens, collectively referred to as "Information Card"
technology. These profiles are agnostic with respect to the format and
semantics of a security token, but interoperability between issuing and
relying parties cannot be achieved without additional rules governing
the creation and use of the tokens exchanged. This document describes a
set of rules for the use of SAML V2.0 assertions, as defined in SAML2
Core, as security tokens within the Information Card architecture...
Identity providers and relying parties employing the Identity Selector
Interoperability Profile (ISIP) [A. Nanda, Identity Selector Interoperability
Profile V1.0, Microsoft, April 2007] to request and exchange security
tokens are able to use arbitrary token formats, provided there is
agreement on the token's syntax and semantics, and a way to connect the
token's content to the supported protocol features. This profile provides
a set of requirements and guidelines for the use of SAML V2.0 assertions
as security tokens that, where possible, emulates existing SAML V2.0
authentication profiles so as to limit the amount of new work that must
be done by existing software to support the use of Information Cards.
It also provides for the use of SAML assertions in this new context that
is safe, and consistent with best practices in similar contexts. This
profile does not seek to alter the required behavior of existing identity
selector software, or conflict with the profiles defined by ISIP...

The 3rd Generation Partnership Project (3GPP) is specifying the IP
multimedia subsystem (IMS) where SIP is the protocol used to establish
media sessions across different participants. The Session Initiation
Protocol (SIP) "is a signalling protocol, widely used for setting up
and tearing down multimedia communication sessions such as voice and
video calls over the Internet. Other feasible application examples
include video conferencing, streaming multimedia distribution, instant
messaging, presence information and online games. In November 2000,
SIP was accepted as a 3GPP signaling protocol and permanent element
of the IMS architecture for IP based streaming multimedia services
in cellular systems." In the IMS it is possible that a UA attempts to
place an emergency call when the IMS network does not support emergency
services. The edge proxy detects the emergency call and can redirect
the UE using a SIP 380 (Alternative Service) to place the emergency
call using another domain (e.g., using a Circuit Switched network). This
document registers new disposition-types for the Content-Disposition
header that apply to the 'application/3gpp-ims+xml' body used by 3GPP.
The applicability of these content-disposition values are limited to
3GPP IMS. The 'application/3gpp-ims+xml' body has the following two
distinct uses: (1) for redirecting the emergency session to use a
different domain (e.g., using a Circuit Switched call), and (2) for
delivering user profile specific information from the SIP registrar
to an Application Server. New disposition-types for the
Content-Disposition header can only be registered with IANA according
to procedures defined in Section 9 of RFC 2183. This document therefore
registers new disposition-types for the Content- Disposition header
to address specific requirements of the IMS. The new disposition-types
may not be applicable to the general Internet. The new disposition
types are applicable to the "application/3gpp-ims+xml" MIME type...
This document makes certain assumptions regarding network topology and
the existence of transitive trust. These assumptions are generally not
applicable in the Internet as a whole. The mechanism specified here
was designed to satisfy the requirements specified by the 3rd Generation
Partnership Project for IP multimedia subsystem (IMS) for which either
no general-purpose solution was found, where insufficient operational
experience was available to understand if a general solution is needed,
or where a more general solution is not yet mature. Note: Numerous 3GPP
IMS- and UMTS-related specifications have Extensible Markup Language
(XML) definitions. 3GPP Organizational Partners include ARIB, CCSA,
ETSI, ATIS, TTA, and TTC.

An August 2008 report has been prepared by Dan Connolly (W3C TAG Team
Contact) on behalf of the W3C Technical Architecture Group (TAG). The
W3C Technical Architecture Group, originally chartered in 2001, was
formed to "document and build consensus around principles of Web
architecture and to interpret and clarify these principles when
necessary... Web architecture refers to the underlying principles that
should be adhered to by all Web components, whether developed inside
or outside W3C. The architecture captures principles that affect such
things as understandability, interoperability, scalability, accessibility,
and internationalization." Three TAG participants are appointed by the
W3C Director and five TAG participants are elected by the Advisory
Committee. In the August 2008, Connolly summarizes TAG discussions in
three areas: (1) Formats: HTML and ARIA, Namespace Documents. "As design
of Accessible Rich Internet Applications (WAI-ARIA) matured in the WAI
Protocols and Formats Working Group (PFWG) and work started on integration
with host languages, especially HTML, the TAG noted the use of an ad-hoc
namespace mechanism: an aria- prefix on a collection of attributes...
The TAG published a finding on Associating Resources with Namespaces,
which addresses issue namespaceDocument-8. The finding suggests
conventions, from ordinary HTML to dialects using RDDL and GRDDL to RDF,
OWL, and XML Schema, for documenting namespaces and for linking associated
resources... While still in draft form, The Self-Describing Web was updated
12 May 2008; it discusses features of the Web that support reliable, ad
hoc discovery of information, including formats such as Atom, RDFa, GRDDL,
XML, and RDF. Work continued on ISSUE-41, What are good practices for
designing extensible XML languages and for handling versioning?. The
20-May-2008 draft of Extending and Versioning Languages: Compatibility
Strategies incorporates a number of reviews comments..." (2) Protocols:
widget packaging, HTTP scalability, linking. The TAG has opened a new
issue, uriBasedPackageAccess-61, in response to a request for support
from the Web Applications Formats (WAF) community to consider URI based
access and reference to items within a web accessible package... In a
19 June discussion of issue scalabilityOfURIAccess-58, the TAG encouraged
use of XML catalogs as a caching mechanism to mitigate the load that
automated access to DTDs and schemas put on the W3C web site... Protocol
support for linking, e.g. from non-hypertext formats, was in early drafts
of HTTP but did not receive enough implementation experience to be
ratified in RFC 2616 in June 1999. An HTTP Header Linking draft of 14
March 'clarifies the status of the Link HTTP header and attempts to
consolidate link relations in a single registry.'.. Also following our
May meeting in Bristol, we invited comment on the 2 June draft of Passwords
in the Clear, especially from the HTML Working Group and the Web Security
Context Working Group." (3) Naming: XRIs. The TAG is working on comparing
HTTP and DNS to other approaches to persistent naming such as 'info:' and
'xri:' under issue issue URNsAndRegistries-50. While the URNs, Namespaces
and Registries draft has been preempted by other work since the last
update of August 2006, the TAG discovered a 31 May deadline on a ballot
to Approve XRI Resolution v2.0 as an OASIS Standard and summarized its
position: TAG recommends against XRI. In an attempt to facilitate dialog
after this somewhat awkward step, the TAG and the OASIS XRI TC held a
3-July-2008 joint meeting and continue the discussion by email in www-tag
with the goals of improving understanding of our respective positions and
to publically record points of agreement and if necessary irresolvable
disagreement."

XPath is an open standard for querying and transforming XML documents;
however, it is a completely different technology than C# programming,
which you [may] already know. With LINQ-to-XML, you can now do some of
the things provided by XPath in a way you already know how to do them...
A few years ago, I wrote a Blackjack game. The game uses statistics
from a book on expert play and coaches the player in the statistically
best play based on the player's and dealer's hands. The game and source
is available from my website... The game was good enough that a
programmer from Harrah's in Biloxi asked to use the source, and my
understanding is that it is a pillow favor provided at the casino. In
this article, game statistics from a round of play were saved as an
XML file and that file is used for the demos. You can download the game
and save your own statistics or use the XML provided... The first example
shows the basic flow—you are shown some code that uses LINQ-to-XML
to query nodes followed by an equivalent XPath query that accomplishes
the same goal... The XML in Listing Two shows the proper placement of
the namespace jack added to the XML from Listing One. The code in Listing
Three incorporates the namespace in the LINQ-to-XML to obtain the net
amount won (or lost) from the XML file in Listing One. The second half
of the listing uses the XPathSelectElement method and an XPath query to
obtain the same value... Another thing you might want to do is find the
value of child elements. To trim up the code for this example, you can
use the XML in Listing One without the namespace. The LINQ-to-XML uses
imperative code and the XElement object chained together to request
children, and the XPath query uses a value that looks a lot like a file
path statement... Transforming XML Data Using Functional Construction
Functional construction is quite literally a way to create an XML tree
in a single statement by chaining function calls together where
subordinate calls are arguments to the calling method. This same nesting
of method calls is also often used in the CodeDOM namespace to create
code graphs. The XML document in Listing One was created with functional
construction. Quite straightforward really, the XML tree was created by
chaining XElement (and XAttribute) objects together to form the shape
of the XML document and calling the XElement.Save method...

Over the past 10 years, XML has become a common, well-accepted standard
for storing and exchanging data within and between organizations.
Because XML itself is only an abstraction, the success of the format
completely depends on the XML format designed by the organization or
by a group of organizations. Just like any software product, these XML
formats face maintenance challenges as business requirements change.
And it's not just the need for changes in general: XML formats must
often be updated for multiple organizations at the same time for
competitive and market reasons. Maintaining just one XML schema is
relatively simple. Making a change that affects several hundred
organizations, however, can have an immense impact. You can use up
plenty of time and money just to address a simple XML schema change that,
designed correctly up front, causes little more than a extra glance at
the information. This article discusses two things: (1) How to manage
this impact; (2) How to minimize this impact where possible. We use
some very simplistic examples containing cars, tires, and windscreens
and their related companies or resellers. Although not completely
realistic, this is sufficient to describe suggestions to improve the
maintainability of XML formats... You don't want to treat XML schemas
as automatically generated technicalities if you want to keep your XML
formats maintainable in large enterprises and their surroundings. You
can choose from many more ways to improve the maintainability of XML
schemas. You can even describe your XML format in other languages, like
Schematron and RELAX NG. Whatever you use, design the right XML format
up front, and you can meet the needs of everyone involved in the
communication.

There are many aspects of "different versions" when considering the
artefacts defined for the OASIS Universal Business Language (UBL). UBL
is expected to be widely deployed over a long period of time. How it
is specified needs to support deployments in a heterogeneous network
of different levels of implementation in different scenarios with
different participants. Differences in versions can be seen in three
different perspectives of the one specification. This paper describes:
(1) different versions of the UBL standard defined by the UBL technical
committee, (2) different versions of UBL customizations defined by
communities of users, and (3) different versions of deployed code lists
defined by trading partners using UBL. Some aspects described apply
only to UBL because of characteristics of UBL not shared with other
vocabularies. This may limit how other vocabularies can take advantage
of the approaches being used... A user community can create a conformant
customized subset and/or extended version of the UBL schemas by removing
optional standardized constructs and by adding non-standardized
constructs only underneath the document's extension point. A individual
in that community can choose from different versions of value constraints
to layer on top of the community's structural and lexical constraints
based on arbitrary trading partner requirements. These versions are
expressed as code and identifier lists combined with business rules
placed on the values. This illustrates how a single XML vocabulary can
be deployed into a heterogeneous network of differing implementation
levels and different business contexts, while still promoting
interoperability and standardized committee structures. The proposed
processing model supports applications relying on schema-validity for
instance inspection. Using this model, any individual will be able to
access an instance from any other individual in any UBL community.
Combining the document constraints with the out-of-band business
constraints any two parties can successfully interchange information
without schema validity being a barrier to access.