<?xml version="1.0" encoding="UTF-8"?>
<!--

DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER.

Copyright (c) 2012 Oracle and/or its affiliates. All rights reserved.

The contents of this file are subject to the terms of either the GNU
General Public License Version 2 only ("GPL") or the Common Development
and Distribution License("CDDL") (collectively, the "License").  You
may not use this file except in compliance with the License.  You can
obtain a copy of the License at
http://glassfish.java.net/public/CDDL+GPL_1_1.html
or packager/legal/LICENSE.txt.  See the License for the specific
language governing permissions and limitations under the License.

When distributing the software, include this License Header Notice in each
file and include the License file at packager/legal/LICENSE.txt.

GPL Classpath Exception:
Oracle designates this particular file as subject to the "Classpath"
exception as provided by Oracle in the GPL Version 2 section of the License
file that accompanied this code.

Modifications:
If applicable, add the following below the License Header, with the fields
enclosed by brackets [] replaced by your own identifying information:
"Portions Copyright [year] [name of copyright owner]"

Contributor(s):
If you wish your version of this file to be governed by only the CDDL or
only the GPL Version 2, indicate your decision by adding "[Contributor]
elects to include this software in this distribution under the [CDDL or GPL
Version 2] license."  If you don't indicate a single choice of license, a
recipient has the option to distribute your version of this file under
either the CDDL, the GPL Version 2 or to extend the choice of license to
its licensees as provided above.  However, if you add GPL Version 2 code
and therefore, elected the GPL Version 2 license, then the option applies
only if the new code is made subject to such option by the copyright
holder.

        -->
<!DOCTYPE book [
<!ENTITY % ents SYSTEM "docbook.ent">
%ents;
]>
<section version="5.0"
         xml:id="customization-of-schema-compilation-using-scd-for-customizations"
         xml:lang="en" xmlns="http://docbook.org/ns/docbook"
         xmlns:xlink="http://www.w3.org/1999/xlink"
         xmlns:ns5="http://www.w3.org/1999/xhtml"
         xmlns:ns3="http://www.w3.org/2000/svg"
         xmlns:ns="http://docbook.org/ns/docbook"
         xmlns:m="http://www.w3.org/1998/Math/MathML">
    <title>Using SCD for customizations</title>

    <para>When using an external customization file, the JAXB spec requires
    that you use XPath as a means to specify what your customization is
    attached to. For example, if you want to change the class name generated
    from a complex type, you'd write something like:</para>

    <example>
        <title>External customization example</title>

        <programlisting language="xml"><![CDATA[<bindings xmlns="http://java.sun.com/xml/ns/jaxb" version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <bindings schemaLocation="../path/to/my.xsd" node="/xs:schema/xs:complexType[@name='foo']">
    <class name="FooType"/>
  </bindings>
</bindings>]]></programlisting>
    </example>

    <para>While the above process works, the problem with this is that the
    XPath+ <literal>schemaLocation</literal> combo tends to be verbose and error
    prone. It's verbose, because often a trivial target schema component like
    this "global complex type foo" takes up a lot of characters. The xs
    namespace declaration also takes up some space, although in this case we
    managed to avoid declaring the "tns" namespace (that represents the
    namespace that the schema defines.)</para>

    <para>It's also error prone, because it relies on the way schema documents
    are laid out, because the schemaLocation attribute needs to point to the
    right schema document file. When a schema is split into multiple files for
    modularity (happens especially often with large schemas), then you'd have
    to find which schema file it is. Even though you can use relative paths,
    this hard-coding of path information makes it hard to pass around the
    binding file to other people.</para>

    <para>JAXB RI 2.1 and onward offers a better way to do this as a vendor
    extension.</para>

    <para>The key technology to solve this problem is a <link
    xlink:href="http://www.w3.org/TR/xmlschema-ref/">"<literal>schema component
    designator</literal>"</link> (SCD.) This is a path language just like XPath, but
    whereas XPath is designed to refer to XML infoset items like elements and
    attributes, SCD is designed to refer to schema components like element
    declarations or complex types.</para>

    <para>With SCD, the above binding can be written more concisely as
    follows:</para>

    <example>
        <title>External customization by SCD</title>

        <programlisting language="xml"><![CDATA[<bindings xmlns="http://java.sun.com/xml/ns/jaxb" version="2.1" xmlns:tns="http://my.namespace/">
  <bindings scd="/type::tns:foo">
    <class name="FooType"/>
  </bindings>
</bindings>]]></programlisting>
    </example>

    <para><code>/type::tns:foo</code> can be written more concisely as
    <code>/~tns:foo</code>, too. If you are interested in more about the
    syntax of SCDs, read <link
    xlink:href="http://www.w3.org/TR/xmlschema-ref/#section-path-examples">the
    example part of the spec</link>, and maybe <link
    xlink:href="http://www.w3.org/TR/xmlschema-ref/#section-path-ebnf">EBNF</link>.
    If you know XPath, I think you'll find this fairly easy to learn.</para>

    <para>Another benefit of an SCD is that tools will have easier time
    generating SCDs than XPath, as XPaths are often vulnerable to small
    changes in the schema document, while SCDs are much more robust. The
    downside of using SCD is as of JAXB 2.1, this feature is a vendor
    extension and not defined in the spec.</para>
</section>
