1. XML prolog
    2. source The prolog is an optional component of the XML document. If included, the prolog must be appear before the root element. A prolog consists of two parts: the XML declaration and the Document Type Declaration (DTD). Depending on your needs, you can choose to include both, either, or neither of these items in your XML document. The DTD is most oftenly used, so we will discuss its use and purpose first.
  2. referencing an external DTD
      3. There are two type declarations that may be used to reference an external DTD: PUBLIC and SYSTEM. When creating an XML document under the rules of a publicly distributed DTD, use PUBLIC. Otherwise, use the SYSTEM type declaration. The example below shows a prolog that would be used for an HTML document that is using an XML prolog. The DTD is publicly available thanks to the W3C. 
      <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
      Let's take a look at each piece of this external DTD reference.
    1. the XML declaration
      2. This is where you define what version of XML you are using. The current version is 1.0, which it has been for quite some time now. Check out the most recent XML version at w3.org. 
      <?xml version="1.0"?>
      The declaration is not absolutely necessary, but should be included anyways
    2. how to validate XML files against an XML Schema
      3. There are three ways: The third way is the most comprehensive.
      Examples may be found in: ~/esavo-reg-II/playground/xsd-validation/ and in particular stages 02, 16, 17 and of course all others as well.
    3. normative locations of important XSD documents
  3. on catalogs
    4. In a nutshell:
    The XML technologies use lots of URLs. While you are in development mode, you might desire to map the URLs to, say, local files. That's what XML catalogs allow you to do, map URLs. And you can do it without impacting your XML documents.
    Useful links:
  4. how to indicate the schemaLocation of XSD documents inside an XML instance document
    5. source

    Example:
    <?xml version="1.0"?>
<Person xmlns:p="urn:person-schema"
           xmlns:l="urn:last-name-schema"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:person-schema
                            urn:person-schema/person-schema.xsd
                            urn:last-name-schema
                            urn:last-name-schema/last-name-schema.xsd">
    <p:fname>Helen</p:fname>
    <l:lname>Jones</l:lname>
</Person>
    NB:The source above is very old and uses the following namespace for the xsi prefix: 
            xmlns:xsi="http://www.w3.org/1999/XMLSchema/instance
    If that is used, my validate utility fails with "Cannot find the declaration of element" apparently because that namespace URI is too old. Instead, the http://www.w3.org/2001/XMLSchema-instance URI should be used, as shown in the example above.
  5. elementFormDefault: qualified -vs- unqualified
    6. The schema document has elementFormDefault set to qualified. As a result, elements conforming to local declarations must use qualified element names in the instance.

    The above can be explained as follows:

    The schema document has elementFormDefault set to qualified. As a result, elements conforming to local declarations belong to a namespace, and in particular to the target namespace of that schema. Therefore, in the instance document these elements must be qualified either by means of an explicit prefix or through the default namespace (recall that a "qualified" in XSD terminology means simply, belonging to a namespace). This is the same as with any other element that belongs to a namespace.

    The reverse is understood as follows: if a schema document has elementFormDefault set to unqualified, then elements conforming to local declarations are not in a namespace. As such, in the schema document, they must be unqualified. This not only means that they should NOT use an explicit prefix, but moreover, that no default namespace should be defined, since if that were the case (i.e. a default namespace was defined) then these unprefixed elements would belong to that namespace and so would cease to be unqualified and the instance document would not validate against the schema as the schema intended said elements to be in NO namespace whereas in the instance they would be construed as being in a namespace (the default namespace - whatever that may be).

    Therefore the earlier model I had in my mind where I thought that due to the subtleties of elementFormDefault ("qualified" and "unqualified" values) to understand the namespaces to which each element belongs it is not enough to look at an instance document but one also has to look at the schema was WRONG. Looking at the instance document is enough to see the namespaces of each element irrespectively of what may be specified at the schema (in terms of elementFormDefault and targetNamespace). Obviously though, to see whether the instance is valid, one has to look at the schema as well.