This note is related to:
Universal Business Language Version 2.1. Edited by Jon Bosak, Tim McGrath and G. Ken Holman. 04 November 2013. OASIS Standard. http://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html.
This document was last revised or approved by the OASIS Universal Business Language (UBL) TC on the above date. The level of approval is also listed above. Check the “Latest version” location noted above for possible later revisions of this document.
Technical Committee (TC) members should send comments on this document to the TC’s email list. Others should send comments to the TC’s public comment list, after subscribing to it by following the instructions at the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/ubl/.
When referencing this note the following citation format should be used:
[UBL-Governance] UBL Maintenance Governance Procedures Version 1.0. Edited by Ole Madsen, Tim McGrath and G. Ken Holman. 04 March 2015. OASIS Committee Note 01. http://docs.oasis-open.org/ubl/UBL-Governance/v1.0/cn01/UBL-Governance-v1.0-cn01.html. Latest version: http://docs.oasis-open.org/ubl/UBL-Governance/v1.0/UBL-Governance-v1.0.html.
Copyright © OASIS Open 2015. All Rights Reserved.
All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the “OASIS IPR Policy”). The full Policy may be found at the OASIS website.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.
This document and the information contained herein is provided on an “AS IS” basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The OASIS Universal Business Language (UBL) is an important and useful XML standard for exchanging business documents. The more the standard is implemented, the more requirements emerge for new areas of business. Therefore the OASIS Universal Business Language (UBL) TC has documented the processes by which UBL can be further enhanced to address additional requirements.
New and existing implementers analyze the UBL standard looking for a way to express their required business information in XML document structures. But no standard can be all things to all people. There inevitably will be information required for business processes that are not currently supported.
There are many ways implementers can resolve this situation. However, interoperability is inhibited if different approaches are used to address the same business requirements. Interoperability can be enhanced if UBL incorporates common solutions to accommodate these additional requirements.
This Committee Note provides guidance for UBL implementers to contribute proposals for additional business processes including additional document types or additional information requirements for consideration as candidates for the UBL standard. Significantly, these guidelines identify a process that allows implementers to apply their own solutions immediately within their current environment and still contribute these to future releases of UBL.
The aim of this Committee Note is to create security and certainty for organizations and communities investing in UBL implementations by documenting the governance procedures to ensure business requirements are met currently and into the future.
Finally, the document outlines the anticipated release cycle and time schedules for each phase of the OASIS standardization process. This will allow implementers to manage their expectations for candidate proposals and guide them in the timing of their submissions.
OASIS TC Administrator: acts as the Technical Committee Liaison to the OASIS Board for the purpose of keeping the Board apprised of activities related to the TC Process. This is a staff member of OASIS.
UBL TC: the OASIS Universal Business Language (UBL) TC is a voluntary group of OASIS members responsible for the maintenance, development and publication of the OASIS UBL standard.
UBL TC Member: a member of OASIS who has joined the UBL TC and agreed to its IPR policy.
UBL TC Voting Member: UBL TC members who are qualified for voting status.
UBL TC Observer: a member of OASIS who as joined the UBL TC but not agreed to its IPR policy. Observers may attend meetings and subscribe (but not post) to the UBL TC mailing list.
Proposer: a submitter of a proposal for enhancements to UBL.
Subcommittee: a group of UBL TC members contributing specifically in an area of expertise, responsible for analyzing proposals and making recommendations to the UBL TC.
Designated Editor - responsible for editing the information describing the agreed-upon recommendations and incorporating the models, documentation and schema into a complete working draft.
Editor - responsible for editing the prose content and the packaging of the agreed-upon additions and changes to the specification.
Task Group: contributing time and expertise to the horizontal tasks such as generating artifacts for use by the Editors.
Responsible Party: a committee member, subcommittee or task group delegated with responsibility for processing a proposal submission.
The OASIS Universal Business Language (UBL) TC is ultimately responsible for the maintenance, development and publication of the OASIS UBL standard. Appendix B, Current UBL resources contains contemporary information regarding specific resources of the UBL TC.
The committee has open membership to any OASIS member in good standing. Committee members are allowed to actively participate in any of the UBL subcommittees and task groups.
All committee members are welcome to propose suggestions for enhancements to UBL.
UBL TC members are urged to participate in reviewing work products.
See https://www.oasis-open.org/join for information on becoming an OASIS member and joining the UBL Technical Committee.
Voting at the UBL TC is possible only by committee members who are qualified for voting status at the time of the vote, as described in the OASIS Process.
Voting members are required to vote on all motions.
The committee also allows observer status to any OASIS member in good standing. Observers may attend meetings and subscribe (but not post) to the UBL TC mailing list.
This allows interested parties to monitor progress within the UBL TC.
The UBL TC follows the OASIS Technical Committee Process (referred to in this document as the "OASIS Process") found at https://www.oasis-open.org/policies-guidelines/tc-process. The procedures in Section 6, “The pathway to standardization” of this Committee Note conform to the OASIS Process at the time of writing, but OASIS may produce updates that will need to be reflected as revisions to this Committee Note.
All proposals for changes or additions to UBL are considered contributions to OASIS and the UBL TC and must be given on a royalty free (with limited terms) basis as outlined in the OASIS IPR Policy available at:
Committee members agree to this policy on joining the UBL TC.
Proposers who are not UBL TC members accept these conditions when submitting via the public comment channel (UBL-comment). This is the official public comment channel that provides a means for outside input, requests and suggestions to be submitted to the UBL TC. For IPR protection and transparency this must always be the means by which contributions are made by proposers who are not UBL TC Members.
Every contribution is documented, tracked and a Responsible Party is tasked with its disposition.
Proposers should understand that UBL is an open standard. This means that it follows transparent, consensus-based, decision-making procedures. As such the UBL TC cannot ensure that all proposals will be incorporated in their exact form into the UBL standard.
This section explains how to assist the UBL TC in processing your proposal.
It should be noted that a proposal that is incomplete or is a statement along the lines of "UBL should contain a..." will require more time to process than a proposal complete with the information the UBL TC needs to consider and implement the suggestions.
The UBL standard appears complex because of the wide-ranging scope of solutions where it plays a role. Those new to UBL may be unable to find an existing component to support their requirement, or they may create their own extension component unknowingly duplicating an existing component.
UBL has been in production for many years and has been tested and deployed in many organizations. As an example, in Denmark UBL for invoicing has been in production and required by law on a regional and national level for more than 10 years. Occasionally implementers in Denmark identify what they believe are new requirements. In many cases these are already addressed by the UBL standard, though perhaps in a different manner to how the implementers conceived them.
A proposal to include new document types into UBL would benefit from including the following details:
A description of the business process requiring these document types.
An example is the process for Collaborative, Planning, Forecasting and Replenishment described in UBL 2.1 (http://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html#S-COLLABORATIVE-PLANNING-FORECASTING-AND-REPLENISHMENT). This was proposed by a Committee Member who provided all of the information needed.
A description of the context of the use of the document types in enough detail to describe their use in the business process envisaged and the roles of the players involved in their exchanges.
A diagrammatic expression of the activities involved.
For example, a set of UML activity diagrams illustrating the choreography of the exchange of instances of the document types.
A data model of the structures required by the proposed document.
XML Schemas using the contributor's namespace URIs for all components. These must not use the standard UBL namespace URIs.
Example instances conforming to the proposed document model schemas using the contributor's namespace URIs.
A submitter proposing new XML elements for UBL has the responsibility to describe in detail (or assist in describing) the supporting information required for the proposed element. These include the context of use and business case, the element's type, proposed name, description, example values, and any equivalent business terms.
Each XML element in a UBL schema represents a component found in the equivalent UBL data model. These components are defined as Business Information Entities following the terminology from the ISO/TS 15000-5:2005 Core Component Technical Specification (CCTS). This specification is available at:
Those proposers working with CCTS will find the UBL data model, the digital signature extension model and a prototypical empty model all available to be copied as proforma models with which to create new proposals.
http://docs.oasis-open.org/ubl/os-UBL-2.1/UBL-2.1.html#A-THE-UBL-2.1-DATA-MODEL contains useful information about the data modeling concepts used in UBL.
For guidance on the many CCTS fields in the model columns of the spreadsheet, please review the latest version of the UBL Naming and Design Rules Version 3.0 found at:
If at all possible proposals for enhancements should preserve backward compatibility with the previous version of UBL. This is enforced through rules on the acceptable cardinality of proposed changes to elements.
The cardinality of a UBL element means the number of times the element is allowed to exist at the particular point in the document tree (between the immediately-preceding element of another name and the immediately-following element of another name).
Cardinality applies to leaf and branch elements of the document tree.
There are four possible values for cardinality:
the element is optional and cannot be repeated if it exists
the element is mandatory and cannot be repeated
the element is optional and if it exists it can be repeated with immediate like-named element siblings
the element is mandatory and can be repeated with immediate like-named element siblings
In order to preserve backward compatibility with all previous versions of UBL, the cardinality of all proposed new or modified elements is strictly controlled.
For example, backward compatibility means that every conceivable schema-valid instance of UBL 2.0 is also a schema-valid instance of UBL 2.1 and all subsequent minor revisions of UBL. Similarly every schema-valid instance of UBL 2.1 shall also be a schema-valid instance of UBL 2.2 and all subsequent minor revisions of UBL.
The following cardinality scenarios are mandated to preserve backward compatibility:
an existing container element can have only optional additions to its children.
a new container element can have any new, or re-use existing, children, each with any cardinality, including being mandatory.
an existing element can have its minimum cardinality decreased or its maximum cardinality increased. This means an element cannot be removed or deprecated.
Therefore any proposed changes to existing elements should be as follows:
from optional singular to optional multiple
from mandatory singular to mandatory multiple
from mandatory singular to optional singular
from mandatory singular to optional multiple
from mandatory multiple to optional multiple
Guaranteeing forward compatibility is not practical because of the additional elements in forward releases. For example, a UBL 2.1 instance is not guaranteed to be a schema-valid instance of UBL 2.0 because it may contain an element not defined in UBL 2.0.
However it is true that a user of UBL 2.1 choosing only to use UBL 2.0 elements in the UBL 2.1 document will have an instance that is schema-valid with the UBL 2.0 schemas. The UBL Customization Guidelines at http://docs.oasis-open.org/ubl/guidelines/UBL2-Customization1.0cs01.pdf makes reference to potential forward-compatible processing by pruning from a document those elements that a system does not recognize.
UBL is a transactional data language and as such there is no concept of "paragraphs of text", “field lengths” or other presentational facets.
A single element of a textual data type is a continuous string of text from the start tag of the element to the end tag of the element without any formatting characteristics.
UBL does support repeating textual elements but only where the same information may be required in different languages. These are not designed to convey different sets of information – such as different paragraphs or lines.
Therefore a proposal for a textual element (such as a description) may have multiple cardinality but if repeated each instance should contain different translations of the same information (indicated by a language identifier).
All UBL document schemas provide an extension point to accommodate additional information elements. This extension point provides a technical solution for custom requirements to be met within standard UBL documents.
However, interoperability is inhibited if each implementer uses the extension point syntax differently to express the same requirement.
Namespaces are critically important in XML, and thus are critically important in UBL. Unfortunately, the simple concept embodied by XML namespaces is often misunderstood, leading to confusion with users. Regrettably, the verbose nature of UBL namespaces contributes to the mistaken impression that the namespaces somehow are adding to the complexity of the XML in UBL documents.
This Committee Note does not attempt to explain the technical declaration syntax for XML namespaces. See Appendix C, Declaring namespaces for more details regarding choosing and using namespaces.
A proposal to the UBL Technical Committee may also benefit from including representative XML schemas that satisfy the requirements of the proposal. These may be those used in an actual implementation by the proposer.
If the proposer wishes to submit demonstration schemas that remain compatible with existing UBL document types, then the proposed new components must be implemented as UBL Extensions.
Proposers may submit an XML schema based on the UBL Extension to illustrate their proposal.
The use of the UBL Extension in a proposal does not signify that the extended content itself will become part of the UBL standard. If deemed appropriate the UBL TC will incorporate the proposed elements in the libraries or document types of the next release.
Proposers may choose to hand-craft their schemas. Alternatively they may choose to copy the UBL Signature Extension spreadsheet (as an example) and use publicly-available tools to generate the schemas.
The UBL TC does not provide a schema generation service for those creating their own document models or proposing enhancements to UBL. Interested parties seeking assistance may use publicly-available software or consult with companies who can provide such a service. The UBL community web site has listings of candidate products and services at, respectively, http://ubl.xml.org/products and http://ubl.xml.org/services.
A UBL extension is presented in XML using three custom non-standard-UBL namespace URI strings. One string is for the extension apex, one is for the non-Standard-UBL aggregates and association components, and one is for the non-standard-UBL basic components. The standard-UBL namespace URI strings are used for those UBL components that already exist in the standard-UBL model and schemas.
If the proposer wishes their demonstration schemas to describe the desired document type incorporating their additions then the proposer is obliged to use non-Standard-UBL namespace URI strings for all components.
While this will be compatible (but not conformant) with the UBL standard at the time of the submission, if the proposed changes are adopted fully then simply changing the namespace URIs would identify the standard UBL Schema.
There are two methods to propose a submission to the UBL TC:
Anyone who is a UBL TC member can propose a submission by raising this as an issue within the UBL TC.
Any person or organization who is not a UBL TC member can propose a submission by subscribing to the UBL-comment list and then posting their contribution.
All contributions and subsequent discussions must be submitted to the UBL public comment list under the terms of the OASIS Feedback License, which assures potential implementers and OASIS that the contribution may be used by the UBL TC in a way that is consistent with its charter and licensed as Royalty Free (with Limited Terms) as defined by the OASIS IPR Policy.
While this mail list is not meant for general discussion purposes, the committee is obliged to solicit answers from the submitter to questions about the submission through the same list so as to any answers are treated as additional information to the original submission.
All exchanges on the UBL public comment list, be they questions or submissions of any kind, are publicly-archived and individual posts may not be removed from the archive.
Proposers should note that the more time the UBL TC has to review a contribution before the release cycle deadlines, the more chance the submission will get full consideration. Any submission received that is not able to have full consideration may be delayed for consideration in a later release.
Once a proposal has been submitted the Responsible Party will evaluate the proposal and notify the UBL TC of their finalized dispositions and their recommendations. This may involve sets of enhancements for the next UBL release.
If the UBL TC approves the recommendations it then incorporates the enhancements into the draft models (including any additional documentation) for the next release.
If the UBL TC does not approve the recommendations then it may make suggestions for the enhancements before they may be reconsidered.
The proposers may review the draft models before they are created as candidate schema.
Once approved the Designated Editors incorporate the enhancements (models, documentation and schema) into the draft set of new UBL specifications referred to as the Working Draft.
The UBL TC review the changes made by the Designated Editors and approve that the Working Draft is ready to go towards standardization. This review is scheduled according the planned UBL Release Cycle.
The UBL TC then proceeds with the OASIS Process for production of an OASIS standard. This will include synchronizing with ISO/IEC JTC 1 on the maintenance of ISO/IEC 19845.
The formal stages of the OASIS Process are illustrated above and summarized as follows. The UBL TC will publish target dates during the completion of each of the stages. Refer to the OASIS website for changes to this process:
A series of working drafts of the next release are developed as required until 11 months before a publication target.
This would normally be at the beginning of the calendar year for which a publication is scheduled.
When the UBL TC has consensus that a working draft is stable and ready to proceed, no more additions will be accepted for the targeted release.
The Editor(s) prepare both a Committee Specification Draft (CSD) 1 package and a Public Review Draft (PRD) 1 package, both dated for the following meeting. This is based on the Working Draft with changes only to the cover page and any other non-material edits appropriate to the package (such as in the release notes and revision history appendixes).
At the following meeting the UBL votes on the following two motions (each requiring a full majority vote):
“To approve the specific working draft as the given Committee Specification Draft (CSD) package.”
“To approve the given Public Review Draft package for a public review period of 30 days.”
Public Review comments from outside of the UBL TC may be received through the UBL-comment list.
Members of the UBL TC may also submit comments either in meetings or through the UBL mailing list.
Every comment received is registered and tracked through its disposition in a transparent and open manner.
At the end of the public review the editors create a proposed Disposition of Comments in which every comment received is disposed as agreed.
Any substantive changes required (that is, changes that impact on validation and conformance) will trigger creating new working drafts, a CSD2 package and PRD2 package. The UBL TC may then approve another public review period, either for 15 days (if only fixing issues that were added) or 30 days (if substantial additional content had to be added on an exceptional basis). The UBL TC will decide on the appropriate review period.
The previous step repeats until all comments received are accommodated with only non-material changes that impact on validation and conformance, after which no more changes will be accepted for the given release. If testing or reviews reveal a backward compatibility or other serious issue this may require a restart of the process.
Based on the number of reviews the UBL TC would hope to conclude this stage by the middle of the calendar year of publication.
The UBL TC solicits OASIS member companies to submit a Statement of Use for the new release.
The Editor(s) prepare Committee Specification 1, dated for the meeting scheduled at least 7 days after the end of the last public review, based on the final Committee Specification Draft with changes only to the cover page and any other non-material edits appropriate to the package (such as in the release notes appendix and the act of removing the revision history appendix)
At the meeting scheduled at least 7 days after the last public review, the UBL TC votes on the following two motions (each requiring a full majority vote:
“To approve the proposed Disposition of Comments as finalized”
“To approve requesting TC Administration hold a Special Majority Vote for the advancement of the Committee Specification Draft as the prepared Committee Specification 1”.
The Editor(s) prepare the Candidate OASIS Standard 1, dated to correspond with the end of a Special Majority Vote by the UBL TC. This is scheduled following negotiation with OASIS TC Administrator.
At a meeting following the approval of the Committee Specification (Step 14), the UBL TC votes on the following motion (requiring a full majority to pass):
“To approve requesting the OASIS TC Administrator to hold a Special Majority Vote to submit the Committee Specification as the given Candidate OASIS Standard”.
If the ballot is successful the editors prepare a complete submission package as described in the current OASIS Process, including the received Statements of Use.
OASIS TC Administrator reviews the package for at least 15 days and then conducts a 60-day public review.
With no inordinate delays the public review would end about mid-October of the release year.
If changes are required as a result of the public review then the process restarts back at the Committee Specification Draft stage (step 13) towards Committee Specification 2.
If no changes are required then the UBL TC chair requests OASIS TC Administrator to hold a Special Majority Ballot for the UBL TC to approve continuing with the OASIS Standard ballot.
OASIS TC Administrator holds a 14-day ballot for all OASIS Members to approve the proposed OASIS Standard.
The Editor(s) prepare the putative OASIS Standard deliverable, dated to correspond with the end of the OASIS Member ballot.
With no inordinate delays the member ballot would end early- to mid-November of the release year.
At their meeting following the approval of the OASIS Standard the UBL TC votes on the following motion (requiring a full majority to pass):
“To approve requesting the OASIS TC Administrator hold a Special Majority Vote of committee to request OASIS TC Administration submit the new UBL standard to ISO/IEC JTC 1 as an amendment to ISO/IEC 19845”.
The Editor(s) prepare a publication of the new UBL standard in the format conforming to ISO/IEC Directives. This may also happen periodically through the process so as not to have any surprises after the Standard is completed.
After successful conclusion of a 4-week Member Review for member feedback regarding the submission request, the OASIS TC Administrator considers the request and may forward the Standard to ISO/IEC JTC1 as a revised version of ISO/IEC 19845.
With no inordinate delays the submission should happen about mid-January of the year following the release year
The subsequent ISO/IEC processes are dictated by their Directives.
To ensure predictable scheduling the UBL TC proposes to publish revisions to the UBL standard every three years. For example, the UBL 2.1 standard was published in late 2013 and so the next release is targeted for late 2016.
Online and downloadable versions of this release are available from the locations specified at the top of this document.
This OASIS Committee Note is published as a zip archive in the http://docs.oasis-open.org/ubl/UBL-Governance/v1.0/cn01/ directory. Unzipping this archive creates a directory tree containing a number of files and subdirectories. Note that while the XML file comprises the revisable version of this specification, this revisable XML may not be directly viewable in all currently available web browsers.
The revisable form of the cover document.
An HTML rendering of the cover document.
A PDF rendering of the cover document.
There are two subdirectories in the package:
DocBook documentation support files
At the time of writing there are two teleconferences that make up a single weekly meeting of UBL technical committee members. This is for the convenience of members from around the world to be able to participate in active discussion. Please see the committee home page for the current meeting details at:
A Google spreadsheet, termed the "master spreadsheet", contains the latest state of all document types and business objects in UBL. Designated model editors are directed by the technical committee to incorporate subcommittee recommendations in the models by editing the master spreadsheet. The spreadsheet location, instructions and colour legend are found in the summary document at:
Each of the subcommittees can use their own means, including their own copy of the Google spreadsheet, in order to draft their recommendations to the Technical Committee.
The Schema Generation Task Group (SGTG) create schemas for the UBL standard. The tools used by the SGTG are publicly.
Working drafts are stored in the committee's Kavi repository of documents as ZIP files at:
These resources are linked from the help document describing the conventions and instructions:
The focus of this appendix is to guide the reader regarding the selection of XML namespaces used in UBL and in user contributions to the committee.
The sole role of namespaces in UBL documents is to distinguish element names found in separate collections of element names where the element names otherwise would be ambiguous because they have the same spelling. A simple example in UBL is the comparison of the ABIE named "Location" and the BBIE named "Location". These are different Business Information Entities and so the components have different XML element structures. The ABIE named "Location" is comprised of elements as children. The BBIE named "Location" is comprised only of text. They cannot both be expressed in a single XML document using the markup <Location> as neither the user nor the XML processor interpreting the markup knows which ASBIE (pointing to the ABIE) or BBIE component is being referenced. Therefore, to avoid ambiguity, the identically-named components must come from separate collections.
To avoid ambiguity users of UBL have the responsibility to use unique user-defined namespaces for their defined components, and to use only the standard UBL namespaces for standard-UBL components.
While the choice of a unique namespace prefix name is irrelevant to the XML process, good practice promotes human understanding. Accordingly, the UBL Naming and Design Rules chooses to use the same set of abbreviations for all UBL namespace prefix names. The rules also define the empty prefix be used for XML root elements (the top-most element or very first element that surrounds all information).
In UBL all Library ABIEs belong in a single collection.
XML namespace URIs should be considered as organizational assets, and as such, they should be managed accordingly. Care should be taken when defining a URI string for a collection that that string has not already been used for a different collection elsewhere in the organization's XML corpus.
URL strings have a strict (but unenforced) syntax of an absolute URL that should use a domain owned by the user. URN strings have a strict (but unenforced) syntax of allowed values in the second field, called the "URN Namespace" (for example, OASIS has formally registered "oasis" as a URN namespace and so is allowed to use it). There is a back door in the URN scheme that allows anyone to use what is termed an "experimental" URN namespace. As such there is no attempt to assert the namespace is anything other than something used temporarily or for experimental purposes.
Thus, if a user is not managing namespace URIs as organizational assets, it would be entirely appropriate to use the experimental URN namespace for the User Extension Apex ABIE, User Document ABIE, User Library ABIE and User BBIE collections along the lines as follows (only one URI for each collection):
Abbreviated, respectively, using prefix names along the lines of myx:, myd:, mya: and myb:
An example of a managed set of namespaces would be to use URLs to the organizational web site. This ensures no other organization following proper etiquette would create an ambiguously-identical namespace URI string, whereas two organizations could very well create identical experimental URN strings. Using a URL for the URI string provides an added benefit that the URL could deliver information to a browser should anyone attempt to dereference the URL. A common practice is to create an XHTML page with RDDL attributes that guides the reader to information about the XML namespace. As mentioned before, an XML processor uses the namespace URI as just a string, so the fact that the string happens also to be a URL does not require the URL to actually exist. Examples of URLs to use as namespace URIs are:
Abbreviated, respectively, using prefix names along the lines of mx:, md:, ma: and mb:
The following individuals have participated in the creation of this specification and are gratefully acknowledged:
|Oriol Bausa Peris, Individual|
|Kenneth Bengtsson, Alfa1lab|
|Peter Borresen, Document Engineering Services Limited|
|Jon Bosak, Individual|
|Kees Duvekot, RFS Holland Holding B.V.|
|Martin Forsberg, Swedish Association of Local Authorities & Regions|
|G. Ken Holman, Crane Softwrights Ltd.|
|Ole Madsen, Danish Agency for Digitisation, Ministry of Finance|
|Tim McGrath, Document Engineering Services Limited|
|Andrew Schoka, Individual|
Copyright © OASIS Open 2015. All rights reserved.
|04 March 2015|