PINS
– Processing Instruction Name Space
PINS defines Processing Instruction Name Space, to enable the use of multiple vocabularies in the same application, whether as XML, JSON or another format.
Name Space declarations represented as Processing Instructions are clearer then their representation as attributes. Processing Instructions allow further information, enabling optional extensions that processors may support.
Background
The World Wide Web Consortium recommends declaring namespaces using attributes,
where the attribute name defines a prefix when qualified with the prefix xmlns,
and the attribute’s value is the URI of the namespace.
<an-element xmlns:my='http://www.my-name-space.com/'?>
Over many years, I have found this approach to be unsatisfactory, because:
- new xml users are confused by the handling of these special attributes: they appear as a single attribute, but have an effect on all descendent nodes.
- namespace declarations are less easy to spot when there are lots of attributes.
- As there is only one URI permitted, common practice has been to specify a namespace as a location URL. This is fragile as the location of the namespace may change. Eg. Turning on SSL change the scheme from http to https.
The last W3C draft of Namespaces in XML to use processing instructions was
Namespaces in XML – Working Draft 18-May-1998.
This defined namespaces as having prefix as Non Colon Name and ns as URI
<?xml:namespace prefix='my' ns='http://www.my-name-space.com/' ?>
Although more verbose than attributes, as a processing instructions it is clearer.
This also enables further optional information to be added, though none was defined.
We modify these approaches to support backwards compatibility, and new features:
- xml:namespace indicates backwards compatible conversion with attribute form.
ns is used for the URI of the namespace. - namespace is used for extensibility. As this approach may be used in multiple formats, we remove the xml: prefix, and expand the ns to namespace, and use:
- Name for the name the namespace. (IRN)
- Location for where to get further information about the namespace. (IRL)
Backwards Compatible Name Space format
In order to support backwards compatible conversion with attribute form,
we use the existing W3C draft form:
<?xml:namespace
prefix='{NCNAME}'
ns='{URI}'
?>
The scope of this processing instruction is the next element and it’s descendent only,
so that there is a PI for each namespace attribute that has been converted.
In the case where there are multiple PIs applying to the same element with the same prefix, the nearest one applies, as if overwriting the previous declaration.
Extensible Name Space Format
The Name Space Processing Instruction is optional, as are it’s parameters.
When absent, or when present with no parameters,
the default namespace is the empty string, for items that have no prefix.
<?namespace
scope='{end|next|following}'
prefix='{|NAME}'
separator='{|:|space separated list of separators}'
name='{|IRN}'
location='{|IRL}'
version='{|user defined string}'
?>
The scope to which this name space prefix declaration applies. One of:
- following elements and their descendants. (default)
- next element and its descendants.
- end the scope of the prefix.
The prefix used to qualify element and attribute names, indicating they are defined in the name space identified by the name. The default is no prefix, which applies to elements and attributes whose names begin with, or have an absence, of the separator characters.
Separator characters may be may be specified, principally to support other languages.
The default separator is a single colon. Separator characters may be an empty string, or
a white space separated list of separators may be provided. Each separator may be single, multiple or valid combining characters.
The intended effect of this is to apply the namespace to any element or attribute that begins with the prefix + any of the separators.
The name of the vocabulary as an IRN, or the empty string (default).
This is used for comparison of qualified names of elements and attributes.
Locations of information about the vocabulary as an IRL, or the empty string (default).
There may be resources at multiple locations defining the vocabulary.
The location may contain locations (IURLs) of resources that define the vocabulary.
These could be web pages (html), schema (xsd), Linked Data (RDF, etc), or any other,
even the application that wrote the document (as that defines the vocabulary).
Version may be used by some applications to further qualify the namespace.
This may be useful in cases where a document has prefixed extension tags that have become part of the vocabulary, enabling the namespace to change, and the tags to remain the same.
The expectation is that most declarations would take the form of
<?namespace
prefix='{NAME}'
name='{IRN}'
location='{IRL}'
version='{user defined string}'
?>
With the location and version providing additional information about the vocabulary used by the writer of the document. Eg. IRL of the software library documentation, and the version of the vocabulary used.
Namespace validation
Note that namespace scope is specified to be either end, next, or following. This ensures that namespace declarations are placed in front of their applicability in document order. The location of resources describe the namespace, which may include schema.
Validating a document against any particular schema is indicated by seperate processing instructions. A collection of rules across schema may be applied to validate (parts of) the document to determine what is valid according to which rules. It is possible to have multiple schema apply to a single namespace.
Schema Location
XML Schema 1.1 specification on schema location says:
5. … Definitions and declarations remain in effect beyond the scope of the element on which the binding is declared.
4.3.2 How schema definitions are located on the Web,
W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures
This is typically implemented so that only the first schemaLocation declaration per namespace is applied, with following declarations ignored.
Best practice is to include the namespace and schemaLocation declarations on the root element. The schemaLocation is a claim by the document writer that it conforms to those particular schema. Document readers may use their own schema by configuration, for determine whether the document is valid according to their own rules.
XML Model
Associating Schemas with XML documents 1.0 (ISO/IEC 19757-11:2011:EN)
enables XML documents to reference multiple schema of various kinds.
For their example, we replace the xmlns attribute with either
xml:namespace PI, or namespace PI which adds a version and a location.
<?xml version="1.0"?> <?xml-model href="http://www.docbook.org/xml/5.0/rng/docbook.rng" schematypens="http://relaxng.org/ns/structure/1.0"?> <?xml-model href="http://www.docbook.org/xml/5.0/xsd/docbook.xsd" schematypens="http://www.w3.org/2001/XMLSchema"?> <?xml:namespace ns='http://docbook.org/ns/docbook' ?> <?namespace name='http://docbook.org/ns/docbook' location='https://docbook.org/ns/' version='5.0' ?> <book> … </book>