Jettison is a collection of StAX parsers and writers which read and write JSON. This allows nearly transparent enablement of JSON based web services in services frameworks like CXF.

There are currently two included conventions for mapping JSON to XML. The first, is BadgerFish which implements
the full XML infoset in JSON using various techniques. The second, is called the "mapped" convention. It allows you to manually map XML namespaces to JSON element prefixes.

Jettison was developed for usage in XFire and CXF to enable JSON based services.

Developers working in the enterprise are confronted by XML documents (SOAP Payloads, Customer Purchase Orders, Application Data) that each have a different version and are described by various schemas. This article is about an idea I have for a java framework for processing versioned XML documents. Many people think that the eXtensible part of XML means somehow that XML documents are more versionable than other documents. This is not the case. That X simply means that the original DTD/XML spec allowed you to create a fixed new grammar that described a set of documents. Instances of a specific XML grammar are not any more versionable than any other data format. This article focuses on versioning at the XML level.

One of the first principles of a versioning framework is to ignore what you don’t understand.

Requirement 1: The XML Processor must ignore any content it does not understand.

SOAP has a simple mechanism for indicating in the processing model that something must be understood. If you do make non-backward compatible changes you will want to signal to the framework that it should fault if it encounters the new element. This leads to requirement 2, that you must be able to signal required elements. A sub requirement to this is that content which is not understood is preferred.

Requirement 2: The processor must fault if it encounters an element that it must understand.

The last requirement is that it must be possible to create applications that are both forward and backward compatible using the versioning framework.

Requirement 3: Applications must be both backward and forwards compatible.

The following section outlines a proposal for the versioning framework. It has five new attributes mustUnderstand, mayIgnore, version, ref, vref. The above requirements coupled with these attributes lead to a generic processing framework that all XML processors can use and is not coupled to any specific XML vocabulary.

Attribute: mustUnderstand
Definition: All processors must understand any element tagged with this attribute, they also mustUnderstand all children of this element except those elements specifically tagged with mayIgnore
Values: true | false

Attribute: mayIgnore
Definition: All processors may ignore this element
Values: true | false

Attribute: version
Definition: identifies this element as belonging to a specific version of the grammar
Values: integer ( . integer ) *

Attribute: vref
Definition: allows the document to target an element identified by a vid attribute
Values: String

Attribute: vid
Definition: the target of the vref element
Values: String

Examples:

<doc xmlns:ver=”http://cfry.net/xml_versioning”>

   <element ver:mustUnderstand=”true” version=”1.0”>

        …. Content

    </element>

    <element2 ver:mayIgnore=”true” version=”2.0”>

    </element2>

</doc>

The following fragment illustrates some things that you can do with namespaces:

<doc xmlns="myNamespace" xmlns:pre="myNamespace" xmlns:pro="myNamespace">
<pro:A pre:a="foo" b="foo">
<C>
<B xmlns="" pro:a="foo" xmlns:pro="bar"/>
</C>
</pro:A>
</doc>

The following output (from the stream API) indicates the namespace of the elements in brackets. Some things to note, if you undeclare the default namespace the element that contains that redeclaration is not in the default namespace. Also you can use a namespace declaration in an attribute list before you declare it.

START_ELEMENT [<['myNamespace']:doc xmlns="myNamespace" xmlns:pre="myNamespace" xmlns:pro="myNamespace">]
START_ELEMENT [<['myNamespace']:pro:A ['myNamespace']:pre:a="foo" b="foo">]
START_ELEMENT [<['myNamespace']:C>]
START_ELEMENT [<B xmlns="" xmlns:pro="bar" ['bar']:pro:a="foo">]
END_ELEMENT [</B>]
END_ELEMENT [</['myNamespace']:C>]
END_ELEMENT [</['myNamespace']:pro:A>]
END_ELEMENT [</['myNamespace']:doc>]

The first thing to note is that namespaces are scoped. That is, you can rebind them in the scope of the startelement that declared them. Anything that references the prefix will get bound to the new uri. This is to allow documents to be nested inside other documents and not have their namespaces change. The default namespace is attached to anything that is not specifically bound with a prefix. You can undeclare the default namespace by binding it to "". You can also have multiple prefixes bound to the same uri. This creates situation where unless you know the prefix used to bind the uri to the local name you can never recreate the document.

Attributes and Namespaces

Many people think that attributes are automatically put into the namespace of the element that declares the attribute. This isn't true. Attributes are in the default namespace (if it is active) or in the namespace that is bound to the prefix that is declared.

QName

Prefixes are part of the XML Infoset http://www.w3.org/TR/xml-infoset/#infoitem.element

They are defined here http://www.w3.org/TR/REC-xml-names/#ns-qualnames

They are explicitly referenced in the XPath API http://www.w3.org/TR/xpath#predicates

Why do prefixes matter?

1) Philosophical: prefixes are explicitly part of the the XML Infoset. Therefore parsers/processors should be required to always report them.

2) A large majority of XML applications actually use prefixes. It is extremely common for developers to utilize prefixes in their applications, even if they strictly don't need to or shouldn't. It's treated like an alias for the namespace URI. (Of course, it's not a good idea for developers to treat it as an alias since the prefix is only properly valid in it's declared scope, but still some do). Therefore, since prefixes are widely used, it doesn't make sense to burden the majority of developers with a prefix-free QName for the minority of developers who in practice don't use prefixes.

Prefixes and Canonicalization

http://www.w3.org/TR/xml-c14n#NoNSPrefixRewriting

4.4 No Namespace Prefix Rewriting The C14N-20000119 Canonical XML draft described a method for rewriting namespace prefixes such that two documents having logically equivalent namespace declarations would also have identical namespace prefixes. The goal was to eliminate dependence on the particular namespace prefixes in a document when testing for logical equivalence. However, there now exist a number of contexts in which namespace prefixes can impart information value in an XML document. For example, an XPath expression in an attribute value or element content can reference a namespace prefix. Thus, rewriting the namespace prefixes would damage such a document by changing its meaning (and it cannot be logically equivalent if its meaning has changed).

More formally, let D1 be a document containing an XPath in an attribute value or element content that refers to namespace prefixes used in D1. Further assume that the namespace prefixes in D1 will all be rewritten by the canonicalization method. Let D2 = D1, then modify the namespace prefixes in D2 and modify the XPath expression's references to namespace prefixes such that D2 and D1 remain logically equivalent. Since namespace rewriting does not include occurrences of namespace references in attribute values and element content, the canonical form of D1 does not equal the canonical form of D2 because the XPath will be different. Thus, although namespace rewriting normalizes the namespace declarations, the goal eliminating dependence on the particular namespace prefixes in the document is not achieved.

Moreover, it is possible to prove that namespace rewriting is harmful, rather than simply ineffective. Let D1 be a document containing an XPath in an attribute value or element content that refers to namespace prefixes used in D1. Further assume that the namespace prefixes in D1 will all be rewritten by the canonicalization method. Now let D2 be the canonical form of D1. Clearly, the canonical forms of D1 and D2 are equivalent (since D2 is the canonical form of the canonical form of D1), yet D1 and D2 are not logically equivalent because the aforementioned XPath works in D1 and doesn't work in D2.

Note that an argument similar to this can be leveled against the XML canonicalization method based on any of the cases in the Limitations, the problems cannot easily be fixed in those cases, whereas here we have an opportunity to avoid purposefully introducing such a limitation.

Applications that must test for logical equivalence must perform more sophisticated tests than mere octet stream comparison. However, this is quite likely to be necessary in any case in order to test for logical equivalencies based on application rules as well as rules from other XML-related recommendations, working drafts, and future works.

1. Configuration Data
2. Data Description
3. Programming Language/Scripting Tool

Configuration Data

In Weblogic Server we use XML to describe our server configuration.

<Server> ... config data ... </Server>

Rowset Data

XML can clearly be used to describe data and is often seen in rows

Interpreter

Ant is the best example of using XML for scripting.