Policies on Modules1
John I. Bobbitt
POSC
License Agreement: © 2004, Petrotechnical Open Standards Consortium, Inc. All rights reserved. All access, receipt, and/or use of this document is subject to the POSC Product Licensing Agreement posted on the POSC Web site at http://www.posc.org/about/license.shtml.
Abstract: A policy is developed for users of POSC modules. It is also the policy that POSC will follow when using modules from other groups. The policy is subject to discussion and changes based on usage experience.
POSC develops schemas for open, public use. In order that its schemas be of value to other groups, it is necessary that they remain open, stable, and freely available. In order to meet these goals, we are developing guidelines for their use2.
The following characteristics, policies, and practices are being developed to carry out our mission. These are not intended to replace the POSC licensing agreement: http://www.posc.org/about/license.shtml. This agreement remains the legal agreement by which we, and our user communities are bound. Any discrepancy between the policies and practices and the licensing agreement shall be decided with the licensing agreement being the operative statement.
The following statements characterize the intent of our policy.
That all schemas developed and owned by POSC remain under our control.
That all schemas developed by other groups, and used by POSC remain under their control
POSC should be able to comment on such schemas
POSC may copy the schema to insure its availability.
POSC may modify the schema to form strict subsets.
That users of our schemas should use them as is, subject to extensions and modifications consistent with standard profiling rules.
That users of our schemas acknowledge the POSC parentage of these schemas.
That POSC will work with other communities to aid in the incorporation and usability of the POSC modules.
That POSC schemas remain open for use by any group. That no group may restrict the usage and/or dissemination of POSC schemas, or of any documents derived from POSC schemas, by attempting to copyright, trademark, license, or any other restrictive practice.
The following are policies and practices for usage of schemas that have been developed by POSC. The purpose of these are to support the characteristics given above. If any of these policies are found to be detrimental to the overall goals, they will be changed.
POSC retains ownership of all modules3 it develops. Others are free to use the schema, and to work with POSC to profile them as given below. POSC shall approve the schema profiles, and may not accept the profile if the profile operations are at variance with the meaning of the module. Changes to defined profiles and to the schemas beyond the profile rules shall be requested by the groups to POSC, and shall be strictly under the control of POSC and its open process.
Usage of POSC modules implies that the schemas shall be imported, and not included. The POSC namespace declarations shall be maintained in the using document.
POSC will make every effort to meet the needs of user communities when considering suggested modifications. The changes will always be viewed with respect to interoperability, consistent practices, backward compatibility, and other factors that are inherent in any variation from the present way of doing business. POSC may consider producing a distinct, though similar, module if the requested changes are too great.
POSC modules may use modules from other groups. This use will generally be an incorporation of other’s modules and schemas into POSC modules. POSC intends to follow the same practices when importing a module from other groups as it expects when other groups import a POSC module.
POSC reserves the right to copy the schema and place it within the POSC website, subject to the copyright and usage restrictions of the other group. However, POSC will not modify the schema unless and until the ownership of the schema is transferred to POSC by agreement with the other group. POSC will maintain the imported schema in a different namespace from the POSC schemas, and will maintain the appropriate ownership statements and policies of the other group. Any modification needed to the schema shall remain with the owning group.
If use of a module from another group requires that POSC modify its policy of the free and open use of schemas, POSC will recommend against the use of such a module, and will not incorporate it.
POSC expects profiles of its schemas to be developed for particular use by well-defined communities of users for well-defined and distinct business purposes. Profiles may be developed with textual statements, through actual changes to the schema, and through extensions based on standard XML schema methods. These will be further discussed.
A textual statement is merely a statement in a document that defines a particular usage. This statement will be a more restrictive usage, and shall not be a redefinition of an intended usage4. Since the textual statements are separate from the schema, there is generally not any conflict with the development of such statements. There is no requirement that POSC be notified of textual statements for module usage.
The schema may be modified to enforce a profile. Guidelines for valid modifications are the following:
Any optional element/attribute may be made mandatory.
Any element may be reduced in multiplicity. For example, an element with maxOccurs=”unbounded” my be restricted to maxOccurs=”1”.
Any enumerated list may be reduced to fewer choices.
A simple data type may be restricted to a smaller domain.
Any other change which is a strict subsetting may also be valid.
The guidelines for determining if a schema is a subset would be that any XML that is valid for the original schema is also valid for the subsetted schema.
The POSC schema may be copied and physically edited to reflect the subsetting. However, POSC shall remain the owner of the module, and all the rights and restrictions of the basic schema shall devolve to the subsetted schema. For interoperability purposes, it is advisable that the subsetted files be sent to POSC as a registered profile, since such a profile may be useful to other groups.
The extension methods are of three types: (1) Use of different modules or schemas where allowed, (2) extensions of enumerated lists or insertion of the user community list, and (3) some use of schema methods that add additional elements and/or attributes, where the addition is not a replacement for an already defined element/ attribute5.
Extensions are carried out at well-defined, documented places, using standard XML schema methods. In general, extensions occur where global element is defined to be a substitution group, or where a type is defined to be abstract, with the expectation that a user group will define the concrete type. There are specific schema methods and patterns for carrying out such extensions. The redefine schema method SHALL NOT be used.
Enumerated lists are also extended by standard methods, which will be documented with the POSC modules. Any extensions of enumerated lists that cannot be handled by these documented methods shall be considered to be changes to the modules rather than valid extensions, and shall be requested through the POSC change process.
Extensions generally require a schema be developed. The schema shall import the POSC module in the POSC namespace, and the extensions shall be in another namespace. This insures that an XML reader can understand which portions are the POSC standard portions, and which are the extended portions.
POSC intends to maintain a registry of profiles developed based on POSC schemas. Profiles are potentially useful to other communities of users and/or business requirements. All profiles will maintain the openness and free use characteristics of the POSC modules. Ownership of profiles shall remain with POSC to ensure the integrity of the family of profiles for each POSC schema. The user community that developed and uses a profile will be responsible to monitor usage and determine the need for maintenance or enhancement of the profile. Such maintenance will be done together with POSC.
All POSC schemas will contain the following statement:
<!--POSC License Agreement This file is distributed under the POSC License Agreement at http://www.posc.org/about/license.shtml. Use of this file implies agreement with the POSC License Agreement. -->
A schema may be copied by a group for maintenance within its own system. However, the copies must retain this statement. This includes schemas modified in accordance with profiles.
Schemas that represent extensions, and schemas that represent use of a module shall use the schema import element. Since the imported document contains the above statement, it is implied that the rights and usage privileges of the imported document are not changed by virtue of its being imported. A user community may state this explicitly in the importing schema itself, but is not required to:
<!--Imported POSC Document This file is imported from POSC and falls under the POSC License Agreement at http://www.posc.org/about/license.shtml. Use of this file in no way modifies the rights and restrictions of the POSC license agreement. -->
[ANSIX12] X12 Reference Model for XML Design, 2002-10, produced by the ANSI X12 committee, obtainable at http://www.x12.org/x12org/.
[BestPractices] Best Practices Homepage, developed and maintained by XML-dev and Mitre, obtainable at http://www.xfront.com/BestPracticesHomepage.html.
[ComProServ] PIDX XML Standards Master, Version 1.0, RP 3901, produced by PIDX, obtainable at http://committees.api.org/business/pidx/standards.htm.
[EBCCNAM] ebXML RT - Naming Convention for Core Component, 2001-05-10, produced by the ebXML group, obtainable at http://www.ebxml.org/specs/index.htm#technical_reports.
[ebTechArch] ebXML Technical Architecture Specification V1.0.4, 2001-02-16, produced by the ebXML group, obtainable at http://www.ebxml.org/specs/ebTA.pdf.
[FedDevGuide] Draft Federal XML Developer's Guide, 2002-04 (work in progress), produced by the Federal CIO Council, obtainable at http://xml.gov/documents/in_progress/developersguide.pdf.
[FedTagStds] Federal Tag Standards for Extensible Markup Language, 2001-06, produced by LMI, not obtainable from the internet.
[HKGuide] XML Schema Design and Management Guide, (4 parts), Draft versions dated in summer, 2003. Produced by Hong Kong Information Services Technology Division. Available at http://www.itsd.gov.hk/itsd/english/infra/eif.htm.
[IETFKeywords] Key Words for Use in RFCs to Indicate Requirement Level, 1997-03, obtainable at http://www.ietf.org/rfc/rfc2119.txt.
[ISO8601] International Standard Date and Time, 2001-11-10, produced by ISO. A web page that explains the formats is http://www.cl.cam.ac.uk/~mgk25/iso-time.html.
[ISO11179] ISO 11179 Part 5 - Naming and Identification, 1995-12, produced by ISO, obtainable at http://fdr.faa.gov/iso/ISO11179page.htm. There is a later version, that is available from the ISO website,
[UKGuide] e-Government Schema Guidelines for XML, 2002-12, produced by United Kingdom e-Envoy, obtainable at http://www.e-envoy.gov.uk/Resources/Guidelines/fs/en.
[Unicode] Unicode Charts, available at http://www.unicode.org/charts/.
[W3CSchemaDatatypes] W3C Schema Datatypes, 2001-05-02, produced by W3C, obtainable at http://www.w3.org/TR/xmlschema-2.
[W3CNamespaces] Namespaces in XML, 1999-01-14, produced by W3C, obtainable at http://www.w3.org/TR/REC-xml-names/.
[W3CSchemaPrimer] W3C Schema Primer, 2001-05-02, produced by W3C, obtainable at http://www.w3.org/TR/xmlschema-0.
[W3CSchemaStructures] W3C Schema Structures, 2001-05-02, produced by W3C, obtainable at http://www.w3.org/TR/xmlschema-1.
[Xlink] W3C XLink Specification, 2001-06, produced by W3C, obtainable at http://www.w3.org/TR/xlink/.
[Xpath] W3C XPath Specification, 1999, produced by W3C, obtainable at http://www.w3.org/TR/xpath/.
[XSL] W3C XSL and XSLT Specifications, produced by W3C, obtainable at http://www.w3.org/Style/XSL/.
POSC references are available in the following formats:
[html] html format readable by browsers
[doc] MS Word 97/2000/XP
[sxw] OpenOffice writer, v1.0
[IntroModule] Introduction to Modules, Copyright 2002-2003. Available in [html], [doc], [sxw].
[BuildModule] Build a Module - a tutorial. Copyright 2003. Available in [html], [doc], [sxw].
[ImportModule] Importing Modules within your Modules. Copyright 2003. Available in [html], [doc], [sxw].
[Guidelines] Guidelines for XML Schemas, Version 2003. Copyright 2003. Available in [html], [doc], [sxw].
[ModulePolicies] Policies on Modules. Copyright 2002-2003. Available in [html], [doc], [sxw].
[ProfilesAppSchema] Modules, Profiles, and Application Schemas. Copyright 2002-2003. Available in [html], [doc], [sxw].
[XMLTables] XML Tables. Copyright 2003. Available in [html], [doc], [sxw].
[ReferenceData] Reference Data and Enumerated Lists Implemented in XML. Copyright 2002-2003. Available in [html], [doc], [sxw].
[Dictionaries] Examples of XML Dictionary Usage. Copyright 2003. Available in [html], [doc], [sxw]. Accompanied by sample code.
[Relationships] Relationships in XML. Copyright 2003. Available in [html], [doc], [sxw].
[UOMRecs] Unit of Measure Recommendations. Copyright 2002-2003. Available in [html], [doc], [sxw].
1 © 2004, Petrotechnical Open Standards Consortium, Inc. All rights reserved. All access, receipt, and/or use of this document is subject to the POSC Product Licensing Agreement posted on the POSC Web site at http://www.posc.org/about/license.shtml.
2The policies presently in this paper are draft policies, still under construction. Feedback on the viability and feasibility of these policies is welcome.
3 In general, POSC will package its schemas into modules and tables. The use of the term modules in most cases may be considered interchangeable with such schemas.
4 An example of a redefinition would be the following statement for the usage of the Name, NamingSystem, and Version elements of an Identifier. “When giving the identifier of a person, the Name shall be the surname, the NamingSystem shall be the first name, and the Version shall be the middle initial.” Such a statement is clearly a misuse of the original intention.
5 An example of a prohibited extension of the third type would occur in the WellName/Identifier/Name element. The structure should not be extended to carry an element, APINumber, which is covered by the Name, NamingSystem pair.
2003-07-25 Official Policy on POSC Module Usage Page