The element names defined within a schema relate just to that schema. But someone may, for very good reason, want to vary a standard schema. BOSSFed, for instance, base their schemas on the BASDA ones, but include aspects that are special to the stationery business and for which there was no provision in the BASDA ones. To subvert the root schemas makes a mockery of having standards, yet variations are always required.
For example one schema may refer to an element <Reference>, describe how it is used, and record the child elements that it contains. But a company may, for very good reason, wish to use the same tag in a slightly different way, perhaps to include additional child elements whose data is essential to the way they operate.
Namespaces provide a simple way to annotate such variations, make them visible, and still maintain the integrity of XML schemas. A namespace is merely a reference, given as an attribute of the tag to which it refers, and naming the schema that is to be used for the purposes of interpreting that element and any of its child elements.
"xmlns” is the attribute that holds the XML namespace, in this case given as the location and filename of the XSD file that defines the schema to be used.
Namespaces provide important reference information for the analysts and programmers who create XML schemas and write the application programs that process XML files. The rest of this section gives more background, for those others who may be interested.
Schemas commonly reference the originating namespace in the root element, so that a user can view a definition of the elements. If a different namespace attribute is given to a child element, then children elements enclosed within that element can use element names in the way defined in that namespace. A prefix is added to such child element names — if no prefix is present, then it is the original namespace that defines that element.
Suppose a child element is given a namespace such as xmlns:OP="urn:BOSSFed- Order:v1". A subsequent child element might be <OP:Reference>. This means the element name Reference is defined not in the root schema definition, but in the namespace document given the short code "OP”. For our processing purposes it makes no difference, because we work on the full element name of OP:Reference. But if we need to research how this element is to be used, then we will look to the namespace reference, not the root schema reference for answers.
Below is a (stripped-out) example taken from the BOSSFed order schema:
Here the root <Order> element contains a number of namespace statements, all of which we will ignore, but which tell us where to find the original definition of the schema — in this case in both the BASDA and BOSSFed web-sites. Subject to any further statements, the definition of every element in the schema is expected to be found there.
As it happens, there is an element <AdditionalOrderReferences> that is not defined in the BASDA namespaces given at the start, but in a namespace on the BOSSFed website. For the purposes of the schema above, the prefix OP (it could have been anything) is added to the elements concerned including the initial element. The source for the OP elements is given in a namespace attribute of the highest element concerned. We’ll quote the full element names in our template, including the OP prefix, and again we will ignore the namespace attribute as it only describes where the definitions of those elements are held, should we wish to look them up. Note the use of the colon as a separator between the prefix and the element name, and between xmlns and the prefix name.
Article ID: 1865 Created On: Tue, Jul 10, 2012 at 1:42 PM Last Updated On: Thu, Jun 22, 2023 at 4:41 PM