You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a user of the draft (FedRAMP-oriented) SSP metaschema, I need to know what is its namespace and (by implication) its governing authority. Its current namespace, urn:OSCAL-SSP-metaschema is a placeholder and has not (TMK) been vetted by anyone.
Goals:
XML namespaces commonly indicate the governing authority for a family of documents (probably sharing a schema). For example, the Catalog and Profile layers now have namespace "http://csrc.nist.gov/ns/oscal/1.0". (See #306 for more.)
It would be good if the SSP metaschema had a namespace conforming to this (implicit) requirement.
But note also this Issue is not only about namespaces but also by implication about how to attribute 'ownership' or 'maintainership' of these metaschemas and schemas, especially when they are in draft.
Acceptance Criteria
We need a decision on namespace policy (at least short-medium term) and what to do in this case, keeping in mind that we need stable namespaces with no complex contingencies.
Depending on the decision we need Issues for follow-on work such as deploying a "real" namespace identifier for the draft SSP schema; modifying XML to conform to it; documenting namespace policy (possibly as part of Metaschema documentation work).
The text was updated successfully, but these errors were encountered:
We discussed this on 8/15/2019 and the decision was to use the same namespace as the lower (catalog and profile) models. i.e. http://csrc.nist.gov/ns/oscal/1.0.
User Story:
As a user of the draft (FedRAMP-oriented) SSP metaschema, I need to know what is its namespace and (by implication) its governing authority. Its current namespace,
urn:OSCAL-SSP-metaschema
is a placeholder and has not (TMK) been vetted by anyone.Goals:
XML namespaces commonly indicate the governing authority for a family of documents (probably sharing a schema). For example, the Catalog and Profile layers now have namespace "http://csrc.nist.gov/ns/oscal/1.0". (See #306 for more.)
It would be good if the SSP metaschema had a namespace conforming to this (implicit) requirement.
Dependencies:
See file https://github.com/usnistgov/OSCAL/blob/master/schema/metaschema/oscal-ssp-metaschema.xml to confirm the present state of the namespace assignment in this schema.
But note also this Issue is not only about namespaces but also by implication about how to attribute 'ownership' or 'maintainership' of these metaschemas and schemas, especially when they are in draft.
Acceptance Criteria
We need a decision on namespace policy (at least short-medium term) and what to do in this case, keeping in mind that we need stable namespaces with no complex contingencies.
Depending on the decision we need Issues for follow-on work such as deploying a "real" namespace identifier for the draft SSP schema; modifying XML to conform to it; documenting namespace policy (possibly as part of Metaschema documentation work).
The text was updated successfully, but these errors were encountered: