A markup language is a mechanism to identify structures in a document. The XML specification defines a standard way of adding markup to documents.

So XML is Just Like HTML?

No. In HTML, both the tag semantics and the tag set are fixed. An <h1> is always a first level heading and the tag <ati.product.code> is meaningless. The W3C, in conjunction with browser vendors and the WWW community, is constantly working to extend the definition of HTML to allow new tags to keep pace with changing technology and to bring variations in presentation (stylesheets) to the Web. However, these changes are always rigidly confined by what the browser vendors have implemented and by the fact that backward compatibility is paramount. And for people who want to disseminate information widely, this has to include more than just the latest releases of Netscape and Internet Explorer.

XML specifies neither semantics nor a tag set. In fact XML is really a meta-language for describing markup languages. In other words, XML provides a facility to define tags and the structural relationships between them. Since there’s no predefined tag set, there can’t be any preconceived semantics. All of the semantics of an XML document will either be defined by the applications that process them or by stylesheets.

So XML Is Just Like SGML?

No. Well, yes, sort of. XML is defined as an application profile of SGML. SGML is the Standard Generalized Markup Language defined by ISO 8879. SGML has been the standard, vendor-independent way to maintain repositories of structured documentation for more than a decade, but it is not well suited to serving documents over the web (for a number of technical reasons beyond the scope of this article). Defining XML as an application profile of SGML means that any fully conformant SGML system will be able to read XML documents. However, using and understanding XML documents does not require a system that is capable of understanding the full generality of SGML. XML is a much-restricted form of SGML.

For technical purists, it’s important to note that there may also be subtle differences between documents as understood by XML systems and those same documents as understood by SGML systems. In particular, treatment of white space immediately adjacent to tags may be different.

There are two kinds of steps: atomic steps and compound steps. Atomic steps carry out single operations and have no substructure as far as the pipeline is concerned, whereas compound steps include a subpipeline of steps within themselves.

This specification defines a standard library, Appendix A, Standard Step Library, of steps. Pipeline implementations may support additional types of steps as well.

source: http://www.w3.org/TR/xproc/

The basis of some applications is hierarchical data structures plus methods of processing the data. Possible examples are compilers, interpreters and text processors. The former two may use abstract syntax trees (ASTs) to represent results of parsing a program and some other trees to deal with code transformations. Text processors may use trees to represent the structure or the formatting properties of a document.
Although the applications are from different domains, the basic operations on trees are the same. For example, getting list of children is a standard functionality for any tree. Some more advanced operations (for example, getting children with filtering) are also common. The problem is that possibly complex code for the advanced operations should be written and being updated for all the tree models, so maintenance become nightmare.
The possible solution for elimination of code duplication is to unify the tree models. As XML is now extremely popular, it’s reasonable to choose XML as an universal representation for trees. For needs of our work, the most fruitful feature of XML is existence of XML-related standards which in fact are design patterns for tree processing. And one of the most useful standards is XPath. In this paper, we give examples of XML and XPath and discuss benefits of seamless use of XML tools in legacy applications.

Read more on: http://uucode.com/texts/genxml/genxml.html

This document and the Lark software are copyright © 1997 by Tim Bray; all rights reserved. However, Lark is available on the Internet for general public use.

This note applies to the final beta of version 1.0 of Lark, and release 0.8 of Larval, in use in January 1998. In this note, the name Lark refers to both Lark and Larval, unless otherwise noted.

Why Lark?
1 Motivations:

Lark’s creation was driven by the following motivations:

Personal Gratification
Writing language processors is fun, particularly when you have the chance to fix the language.
Desire to Learn Java
It’s about time, and Java seems like the appropriate language for the job.
Test Compliance with Design Goals
In particular, XML Design Principle #4, which states that “It shall be easy to write programs which process XML documents.”
Expore the API Design Space
There is a chance, while XML is young, to make some real progress in the design of processor API’s. The design of Lark makes very few assumptions about the user interface; thus Lark should be useful as an experimental testbed in this area.
$$$
Perhaps Lark will turn out to be useful. I have not the slightest desire to start another software company (been there, done that, got the T-shirts), but it would be nice to figure out a way to get paid for the time I’ve put in writing it.

2 Conclusions:
Yes, writing Lark was fun. In particular, none of the innocent-looking things in XML turned out, in practice, to be too horribly difficult. And Java is indeed a Happy Hunting Ground for programmers.

On the design-goal-compliance front, the good news is that if you wanted a program to process XML that you knew was well-formed, you could probably bash it out in perl (don’t know about Java) in a day or so. On the other hand, if you want to build a general-purpose tool that does all of XML and provides helpful error messages and a useful API, the nominal week is not nearly enough. The development of Lark has consumed about a month at this point in time, stretched over a year’s elapsed time.

I do think that Lark will be useful for exploring API designs. Of course, none of this will happen unless there are people out there who want to use an XML processor for something or other. Among other things, Lark currently has no user interface at all; while I don’t mind editing the Driver.java file and recompiling to run tests, presumably a UI would be a good thing to have.

As for the financial aspects, I’m kind of gloomy. I think most XML processors are going to be purpose-built for the needs of particular applications, and will thus hide inside them. Which is good; XML’s simplicity makes this approach cost-effective. Failing that, processors will be full-dress validating parsers with incremental parsing for authoring support. So I’m not sure that there’s all that much need for a standalone processor; but I’d love to be wrong.

Just in case, for the moment I’m going to be giving away all the .class files, and some of the Java source code, but not the source code for the three classes with the hard bits. In any case, they’re sure to be buggy at this stage and I wouldn’t want to be letting them out of my hands with a bit more polishing. If you can see a way to get a little revenue out of this project, give me a call.

Lark Feature Set Overview:

1 Compactness
(The figures below refer to Lark 0.97; they will be updated for 1.0 when it comes out of final beta status.)

Since an XML processor is often going to run on the client and presumably need to be delivered over the network, it must be compact. At the moment, the total byte count is around 45K, which is not too bad.

There is some more scope for compression, when some useful facilities appear in the Java class libraries that ought to be there; e.g. usable symbol table and better Unicode support.

2 Performance
At the moment, Lark, running under the Win95 J++ “Jview” application viewer on an underconfigured P100 notebook, runs at about 200K/second. I am fairly happy with this performance, and doubt whether a full-featured processor implemented in Java can really be made to run much faster.

3 Completeness
Lark is a processor only; it does not attempt to validate. It does read the DTD, with parameter entity processing; it processes attribute list declarations (to find default values) and entity declarations. Lark is relatively full-featured; it implements (I think) everything in the XML spec and reports violations of well-formedness.

Lark’s error-handling is draconian. After encountering the first well-formedness error, no further internal data structures are built or returned to the application. However, Lark does continue processing the document looking for more syntax errors (and in fact performing some fairly aggressive heuristics on the tag stack in order to figure out what’s going on), and calling the doSyntaxError application callback (see below) to report further such errors.

Larval is a full validating XML processor; it reports violations of validity constraints, but does not apply draconian error handling to them.

4 API
Lark presents as a set of Java classes. Those named Element, Attribute, and Entity are obvious in their function. One lesson of this activity is that it may be possible for such classes to be shared independent of the parser architecture; it would be very handy if all XML-processing Java apps used the same Element class, at least as a basis for subclassing.

The Text and Segment classes do Lark’s character data management; details are below.

From an application’s point of view, the Lark and Handler classes are central. Handler has methods such as doPI, doSTag, doEntityReference, doEtag; the application passes a Handler instance to Lark’s readXML method, and Lark calls the routines as it recognizes significant objects in the XML document. The base class provides do-nothing methods; the intent is that an application would subclass Handler to provide the appropriate processing semantics.

Along with presenting this event stream to the application, Lark can optionally build a parse tree, and if so doing, can optionally save copies of the XML document’s character data, all in parallel with providing the event stream. Lark provides methods to toggle these behaviors. These methods may be used in the Handler callbacks while Lark is running, to build the parse tree or save the text for only a subset of the document.

In building the parse tree, Lark is guaranteed to update only elements which are still open; i.e. for which the end-tag has not been seen. All other sections of the tree, and the entire tree once Lark has hit end-of-file, may be manipulated freely by the application.

An instance of Lark may be initialized with an optional list of element GI’s which are to be considered as those of empty elements, whether or not the XML “/>” syntax is used. A typical set might begin: “HR”, “BR”, “IMG”, ….

Another initializer allows a set of entities to be predefined.

Lark also provides the application access to the “entity tree”; there is a method that toggles whether Lark attempts to retrieve and parse external entities.

5 Error Handling
Lark makes a serious effort to be robust, by providing useful error messages and continuing to do so after the first error. The error handling is good enough that I now use Lark as my primary tool to debug broken XML files.

6 Text Segment Management
Probably due to my background in the indexing and search business, Lark pays more attention than is perhaps strictly necessary to the location of objects within the XML file. Lark informs the application of the containing entity and begin/end offsets of each element. A chunk of character data in an element, which may look contiguous to an application, may in fact map to several different byte ranges in different entities, due to the effect of entity references. Also, the use of encodings such as UTF8 may cause the number of bytes of underlying document to differ from the number of bytes that makes up the characters in a chunk of text. Lark represents Text objects as a vector of Segment objects, each of which gives information about the source offset and length, and the number of characters in the segment. If text-saving has not been turned on, the segments contain no character data, but still contain the offset information.

7 Entity Handling
Lark does full XML entity handling. Java provides facilities which make this trivially easy. The application can turn the inclusion of external text entities on and off. Lark makes no use of PUBLIC identifiers, aside from passing them to the callback in the Handler upon recognizing the declaration.

8 Concurrency
Lark is thread-safe. Multiple Larks can run in parallel threads, with other threads doing useful processing of under-construction document trees.

source: http://www.textuality.com/Lark/

SOA is not a new concept. Sun defined SOA in the late 1990’s to describe Jini, which is an environment for dynamic discovery and use of services over a network. Web services have taken the concept of services introduced by Jini technology and implemented it as services delivered over the web using technologies such as XML, Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP), and Universal Description, Discovery, and Integration(UDDI). SOA is emerging as the premier integration and architecture framework in today’s complex and heterogeneous computing environment. Previous attempts didn’t enable open interoperable solutions, but relied on proprietary APIs and required a high degree of coordination between groups. SOA can help organizations streamline processes so that they can do business more efficiently, and adapt to changing needs and competition, enabling the software as a service concept. eBay for example, is opening up its web services API for its online auction. The goal is to drive developers to make money around the eBay platform. Through the new APIs, developers can build custom applications that link to the online auction site and allow applications to submit items for sale. Such applications are typically aimed at sellers, since buyers must still head to ebay.com to bid on items. This type of strategy, however, will increase the customer base for eBay.

SOA and web services are two different things, but web services are the preferred standards-based way to realize SOA. This article provides an overview of SOA and the role of web services in realizing it. The article provides:

* An overview of software as a service
* A tutorial on SOA
* An overview of Sun’s platforms for building web services
* Guidelines for designing interoperable web services
* Challenges in moving to SOA
* An overview of Java Business Integration (JSR 208)
* A discussion of web services for enterprise application integration

Service-Oriented Architecture

SOA is an architectural style for building software applications that use services available in a network such as the web. It promotes loose coupling between software components so that they can be reused. Applications in SOA are built based on services. A service is an implementation of a well-defined business functionality, and such services can then be consumed by clients in different applications or business processes.

SOA allows for the reuse of existing assets where new services can be created from an existing IT infrastructure of systems. In other words, it enables businesses to leverage existing investments by allowing them to reuse existing applications, and promises interoperability between heterogeneous applications and technologies. SOA provides a level of flexibility that wasn’t possible before in the sense that:

* Services are software components with well-defined interfaces that are implementation-independent. An important aspect of SOA is the separation of the service interface (the what) from its implementation (the how). Such services are consumed by clients that are not concerned with how these services will execute their requests.
* Services are self-contained (perform predetermined tasks) and loosely coupled (for independence)
* Services can be dynamically discovered
* Composite services can be built from aggregates of other services

SOA uses the find-bind-execute paradigm as shown in Figure 1. In this paradigm, service providers register their service in a public registry. This registry is used by consumers to find services that match certain criteria. If the registry has such a service, it provides the consumer with a contract and an endpoint address for that service.

SOA-based applications are distributed multi-tier applications that have presentation, business logic, and persistence layers. Services are the building blocks of SOA applications. While any functionality can be made into a service, the challenge is to define a service interface that is at the right level of abstraction. Services should provide coarse-grained functionality.
Realizing SOA with Web Services

Web services are software systems designed to support interoperable machine-to-machine interaction over a network. This interoperability is gained through a set of XML-based open standards, such as WSDL, SOAP, and UDDI. These standards provide a common approach for defining, publishing, and using web services.

Sun’s Java Web Services Developer Pack 1.5 (Java WSDP 1.5) and Java 2 Platform, Enterprise Edition (J2EE) 1.4 can be used to develop state-of-the-art web services to implement SOA. The J2EE 1.4 platform enables you to build and deploy web services in your IT infrastructure on the application server platform. It provides the tools you need to quickly build, test, and deploy web services and clients that interoperate with other web services and clients running on Java-based or non-Java-based platforms. In addition, it enables businesses to expose their existing J2EE applications as web services. Servlets and Enterprise JavaBeans components (EJBs) can be exposed as web services that can be accessed by Java-based or non-Java-based web service clients. J2EE applications can act as web service clients themselves, and they can communicate with other web services, regardless of how they are implemented.

source : http://java.sun.com/developer/technicalArticles/WebServices/soa/

Status of this document:
This Working Draft of XML Signature Requirements is a very stable result of this Working Draft having been advanced through W3C Last Call. Relatively small changes have been made to clarify the stated requirements during that period. This document will now be advanced as an IETF Informational RFC.

Requirements:

1. Signature Data Model and Syntax:
XML-signature data structures must be based on the RDF data model [RDF] but need not use the RDF serialization syntax. [Charter]
XML-signatures apply to any resource addressable by a locator — including non-XML content. XML-signature referents are identified with XML locators (URIs or fragments) within the manifest that refer to external or internal resources (i.e., network accessible or within the same XML document/package). [Berners-Lee, Brown, List(Vincent), WS, XFDL]
XML-signatures must be able to apply to a part or totality of a XML document. [Charter, Brown]

Multiple XML-signatures must be able to exist over the static content of a Web resource given varied keys, content transormations, and algorithm specifications (signature, hash, canonicalization, etc.). [Charter, Brown]
XML-signatures are first class objects themselves and consequently must be able to be referenced and signed. [Berners-Lee]
The specification must permit the use of varied digital signature and message authentication codes, such as symmetric and asymmetric authentication schemes as well as dynamic agreement of keying material. [Brown] Resource or algorithm identifier are a first class objects, and must be addressable by a URI. [Berners-Lee]
XML-signatures must be able to apply to the original version of an included/encoded resource. [WS-list (Brown/Himes)]

2. Format:
An XML-signature must be an XML element (as defined by production 39 of the XML1.0 specification. [XML])
When XML signatures are placed within a document the operation must preserve (1) the document’s root element tag as root and (2) the root’s descendancy tree except for the addition of signature element(s) in places permitted by the document’s content model. For example, an XML form, when signed, should still be recognizable as a XML form to its application after it has been signed. [WS-summary]
XML-signature must provide a mechanism that facilitates the production of composite documents — by addition or deletion — while preserving the signature characteristics (integrity, authentication, and non-repudiatability) of the consituent parts. [Charter, Brown, List(Bugbee)]
An important use of XML-signatures will be detached Web signatures. However, signatures may be embedded within or encapsulate XML or encoded content. [Charter] This WG must specify a simple method of packaging and encapsulation if no W3C Recommendation is available.

3. Cryptography and Processing:
The specification must permit arbitrary cryptographic signature and message authentication algorithms, symmetric and asymmetric authentication schemes, and key agreement methods. [Brown]
The specification must specify at least one mandatory to implement signature canonicalization, content canonicalization, hash, and signature algorithm.
In the event of redundant attributes within the XML Signature syntax and relevant cryptographic blobs, XML Signature applications prefer the XML Signature semantics.
Comment: Another possibility is that an error should be generated, however it isn’t where a conflict will be flagged between the various function and application layers regardless.

The signature design and specification text must not permit implementers to erroneously build weak implementations susceptible to common security weaknesses (such as as downgrade or algorithm substitution attacks).

4.Coordination:
The XML Signature specification should meet the requirements of the following applications:
Internet Open Trading Protocol v1.0 [IOTP]
Financial Services Mark Up Language v2.0 [Charter]
At least one forms application [XFA, XFDL]
To ensure that all requirements within this document are adequately addressed, the XML Signature specification must be reviewed by a designated member of the following communities:
XML Syntax Working Group: canonicalization dependencies. [Charter]
XML Linking Working Group: signature referants. [Charter]
XML Schema Working Group: signature schema design. [Charter]
Metadata Coordination Group: data model design. [Charter]
W3C Internationalization Interest Group: [AC Review]
XML Package Working Group: signed content in/over packages.
XML Fragment Working Group: signing portions of XML content.

source:http://www.w3.org/TR/xmldsig-requirements

When we talk about an XML signature, we are actually referring to an XML document, which contains the Signature (defined in the namespace http://www.w3.org/2000/09/XMLdsig#) as one element (which may be the root element). But the document may also contain other elements, among which the most important are, of course, the original data objects being signed.

Depending on how those data objects relate to the Signature element in an XML Signature document, we consider three different types of XML signatures.

Enveloping: The data objects are contained within the same XML document as the Signature element, and are further included in the Signature element (as sub-elements of Object, for example).

Enveloped: The data object is found within the same XML document as the Signature element, and actually includes the Signature as a sub-element.

Detached: The Signature refers to external network resources, or the data object is within the same XML document as the Signature element, but is a sibling element, or is a sub-element of its sibling element.

Some writings on XML Signature leave readers the impression that this is an exclusive classification of XML signatures; others implicitly suggest that, in enveloping or enveloped signatures, there is actually an Envelop element in the XML document containing the signature; and still others imply that for an enveloping signature, Signature is the root element of the XML document. These are all plainly wrong.

Data Integrity and Message Authentication
The main purpose of XML digital signature is to ensure the integrity of data. RFC 2828, Internet Security Glossary, defines integrity as “the property that data has not been changed, destroyed, or lost in an unauthorized or accidental manner.” Storing or transiting the data together with a checksum can achieve data integrity in this sense. Strictly speaking, XML Signature ensures more than such integrity. It provides support for what RFC 2828 refers to as message authentication, the property “given an authentication code/protected checksum, that tampering with both the data and checksum, so as to introduce changes while seemingly preserving integrity, are still detected.”

source:http://today.java.net/pub/a/today/2006/11/21/xml-signature-with-jsr-105.html

Building XPointer Expressions

The most important component of XPointer expressions is the location path, which is a construct used to describe the path that must be followed to arrive at a node within an XML document tree. Location paths are the building blocks of XPointer expressions, which are evaluated to arrive at a specific location within a tree. More specifically, location paths allow you to traverse siblings, ancestors, children, and descendants of nodes, not to mention attributes. Location paths are broken down into two basic typesabsolute paths and general paths.

Absolute location paths point to a specific location within an XML tree, and therefore aren’t dependent on context. Following are the different absolute location paths defined in XPointer:

*
/ Locates the root node, which is the parent node for the entire document tree
*

id(Name) Locates the element with an attribute ID value of Name
*

here() Locates the node containing the current XPointer expression
*

origin() Locates the sub-resource from which the user initiated a link (used with out-of-line links)

The most important absolute location paths are the root and id() paths. The root path is represented by a forward slash (/), and is often used at the start of an XPointer expression as the basis for absolute location paths. The id() location path is used to locate an element with a specific attribute value.

In addition to absolute location paths, XPointer also defines a rich set of relative location paths. Relative location paths are always relative to some node, which is known as the context node for the path. Following are the relative location paths available for use in XPointer expressions:

*
child Locates child nodes of the context node
*
descendant Locates nodes within the context node
*
descendant-or-self Same as descendant except the context node is also included
*
parent Locates nodes one level above the context node that contains the context node
*
ancestor Locates all nodes above the context node that contain the context node
*
ancestor-or-self Same as ancestor except the context node is also included
*
preceding-sibling Locates sibling nodes that precede the context node
*
following-sibling Locates sibling nodes that follow the context node
*
preceding Locates nodes that precede the context node
*
following Locates nodes that follow the context node
*
self Locates individual context nodes within a list of context nodes
*

attribute Locates attributes of the context node

If you’re totally confused by all this context node talk, don’t worry because it will all make sense in a moment. As confusing as it may seem, the relative location paths in the previous list really are quite useful and are much easier to use than you might think. The next section shows you how to use these location paths to create expressions in XPointer.

Creating XPointers

Seeing a few examples of XPointer expressions can make all the difference in understanding how XPointer is used to define document fragment identifiers. Following is an example of a simple XPointer expression:

child::factoid

This example uses the child relative location path to locate all of the children of the context node that are of element type factoid. Let me rephrase it in a different way: The sample expression locates element nodes of type factoid that are child nodes of the context node. Keep in mind that the context node is the node from which you are issuing the expression, which is a lot like the current path of a file system when you’re browsing for files. Also, it’s worth clarifying that the XPointer expression child::factoid simply describes the fragment identifier for a resource and is not a complete resource reference. When used in a complete expression, you would pair this fragment identifier with a URI that is assigned to an href attribute, like this:

href=”http://www.stalefishlabs.com/factoids.xml#child::factoid”

In this example, a URI is specified that references the XML document named factoids.xml. The XPointer expression is then provided as a fragment identifier, which is separated from the URI by a pound symbol (#). This is the typical way in which XPointers are used, although expressions can certainly get more complex than this.

Read more on Brainbell

With XKMS, developers can integrate authentication, digital signature, and encryption services, such as certificate processing and revocation status checking, into applications in a matter of hours - without the constraints and complications associated with proprietary PKI software toolkits.

Features and Benefits:

1. Easy to develop
The XKMS specification allows developers to rapidly implement trust features, incorporating cryptographic support for XML digital signatures and XML encryption using standard XML toolkits. The developer-friendly syntax used in XKMS eliminates the necessity for PKI toolkits and proprietary plug-ins.

2. Quick to deploy
XKMS moves the complexity associated with PKI deployment to the server side components. Developers can now focus on their core competency of developing applications rather than the complexities surrounding a PKI deployment.

3. Open Standards
The XKMS specification has been submitted to the World Wide Web Consortium (W3C) as an open standard for distribution and registration of keys. The common XML vocabulary used to describe authentication, authorization, and profile information in XML documents makes XKMS services completely platform, vendor, and transport-protocol independent.

4. Future-proof
By restricting the impact of future PKI developments and advancements to the server-side components, XKMS protects developers and applications from becoming incompatible with the latest developments in PKI.

source: http://www.verisign.com/developer/xml/xkms.html

W3C Specifications for XML Encryption Released as Proposed Recommendations. The W3C XML Encryption Working Group has released Proposed Recommendation specifications for XML Encryption Syntax and Processing and Decryption Transform for XML Signature. Pending review of comments from the W3C Advisory Committee Members and the public, the specifications may reach Recommendation status after November 14, 2002. The XML Encryption document “specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data.” The Decryption document “specifies an XML Signature ‘decryption transform’ that enables XML Signature applications to distinguish between those XML Encryption structures that were encrypted before signing (and must not be decrypted) and those that were encrypted after signing (and must be decrypted) for the signature to validate. XML Encryption is a method whereby XML content can be transformed such that it is discernable only to the intended recipients, and opaque to all others. There are many applications for such a specification given the increasing importance of XML on the Internet and Web including the protection of payment and transaction information.” [Full context]

XML Encryption Candidate Recommendation. XML Encryption Syntax and Processing. W3C Candidate Recommendation 02-August-2002. Edited by Donald Eastlake and Joseph Reagle.Second W3C Candidate Recommendation from the XML Encryption Working Group. “This document specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data.” See the “XML Encryption Implementation and Interoperability Report.”

[March 04, 2002] W3C XML Encryption Working Group Releases Candidate Recommendation Specifications. The W3C XML Encryption Working Group has published an updated XML Encryption Requirements document and has approved the release of XML Encryption Syntax and Processing and Decryption Transform for XML Signature as Candidate Recommendation specifications. The working group expects to meet the exit criteria for the two CRs, but solicits additional feedback (until April 25, 2002) based upon on implementation experience. The requirements specification outlines “the design principles, scope, and requirements for XML Encryption; it includes requirements as they relate to the encryption syntax, data model, format, cryptographic processing, and external requirements and coordination.” The core specification for XML Encryption Syntax and Processing defines “a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption EncryptedData element which contains (via one of its children’s content) or identifies (via a URI reference) the cipher data. When encrypting an XML element or element content the EncryptedData element replaces the element or content (respectively) in the encrypted version of the XML document. When encrypting arbitrary data (including entire XML documents), the EncryptedData element may become the root of a new XML document or become a child element in an application-chosen XML document.” The Decryption Transform document ” specifies an XML Signature “decryption transform” that enables XML Signature applications to distinguish between those XML Encryption structures that were encrypted before signing (and must not be decrypted) and those that were encrypted after signing (and must be decrypted) for the signature to validate.” [Full context]

[January 25, 2001] W3C Approves XML Encryption Activity. Joseph Reagle (W3C Policy Analyst, IETF/W3C XML-Signature Co-Chair) posted an announcement to the Public XML Encryption List ‘xml-encryption@w3.org’ indicating that an official W3C XML Encryption Activity has been approved. The XML Encryption Charter has been reviewed by the W3C Advisory Committee, Team, and Director. The [draft] charter says, in part: “The mission of this working group is to develop a process for encrypting/decyrpting digital content (including XML documents and portions thereof) and an XML syntax used to represent the (1) encrypted content and (2) information that enables an intendent recipient to decrypt it. XML Encryption is a method whereby XML content can be transformed such that it is discernable only to the intended recipients, and opaque to all others. There are many applications for such a specification given the increasing importance of XML on the Internet and Web including the protection of payment and transaction information. The proposed work will obviously address how to encrypt an XML documents including elements. The following additional requirements must be met by the WG; these requirements must be augmented and extended by the Requirements Document deliverable: (1) The mechanisms of encryption must be simple: describe how to encrypt/decrypt digital content, XML documents, and portions thereof. a) Only enough information necessary for decryption need be provided. b) The specification must not address authorization, authentication, nor the confidence or trust applications place in the provision of a key though it should enable (or at least not hinder) such XML based technologies. (2) XML-Encryption must be coordinated with and use the work product of other mature XML technologies including XML Schema and XML Signature. (See Coordination) (3) The mandatory portions of the specification must be implemented in at least two independent implementations before being advanced to Proposed Recommendation. The core scope of this activity will be in specifying the necessary data model, syntax, and processing to encrypt XML content. The Working Group (WG) will: (1) Specify a requirements document that further defines the scope and requirements of the WG’s deliverables. (2) Specify the syntax and processing necessary for creating XML Encryption content. The WG should decide what level of granularity is appropriate with the meta-requirement that the design be simple to implement and quickly deployable. (3) Choose a data model (and representation via XML element types or URIs) for describing any necessary public characteristics of the encrypted content (e.g., the data encrypted is an http://someURI#elementNode). The WG must use pre-existing models such as Information Set, XPath, SetX, or DOM. (4) Choose a method (that can be optional) to canonicalize XML prior to encryption such that it can be decrypted consistently. The WG must use a pre-existing canonicalization method such as Canonical XML. (5) Specify a minimal set of encryption and key information for interoperability purposes. This may be a separate document or part of the specification. (6) Address security concerns arising from the design and its implementation. This may be a separate document or part of the specification. (7) Optionally, develop a document of scenarios and recommendations regarding the affects and requirements of XML Encryption processing on XML parsing and validation. This must be a separate document. (8) Redefine the charter for subsequent work once (1-7) has been achieved. The requirement document must specify and describe the WG’s choice with respect to the granularity of encryption, the data model and representation resulting from that choice, and the necessity and choice of canonicalization algorithms. The WG must rely upon existing W3C specifications as building blocks to its own design, unless the WG can demonstrate these specifications fail to meet the requirements of XML Encryption applications. In which case the WG must give a strong rationale and obtain Director approval.” The web site for the XML Encryption WG is publicly accessible.

source: http://xml.coverpages.org/xmlAndEncryption.html