Congrats on your TC's progress with the Cloud Profile spec.
Here are some comments as you continue to produce WDs:
Re: the message about a SAF Cloud Profile document
said to be close to completion "for DMTF-CIMI
(Cloud Infrastructure Management Interface)...."
Symptoms Automation Framework (SAF) Cloud Profile
Working Draft 08
12 Mar 2012
http://lists.oasis-open.org/archives/saf/201203/msg00003.html
http://lists.oasis-open.org/archives/saf/201203/msg00003/SAF-CloudProfile-WD.doc
= Attachment with file name: SAF-CloudProfile-WD.doc
==========================================================
Section 1.3 Namespaces "used"
==========================================================
I read here:
The following namespaces are used in this document:
Prefix Namespace
xsd http://www.w3.org/2001/XMLSchema
sym http://docs.oasis-open.org/symptoms/symptoms_v1
sycl http://docs.oasis-open.org/symptoms/cloud_profile_v1
But the second two items in the list are not allowable, per
the OASIS rules for TC-based allocation of XML namespace names
based upon the official TC short name identifier string:
http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#xml-namespaces
There is no OASIS TC with identifier "symptoms"
An XML namespace name identified by an HTTP scheme URI
reference must conform to the pattern:
http://docs.oasis-open.org/[tc-shortname]/ns/xxxx
Thus the spec would have to indicate, for any XML namespace
name declared in the Work Product "Symptoms Automation
Framework (SAF) Cloud Profile" an initial
http://docs.oasis-open.org/saf/ns/xxxx
Please see the other instructions on XML namespace names
in OASIS specs, and what is meant by "xxxx" above
http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#xml-namespaces
In particular, differentiation needs to be made between
formal namespace declaration and "use" of namespaces
(which are formally declared in other specifications).
==========================================================
2. Spec cover page Declared XML Namespace(s):
==========================================================
There's a comment on the draft cover page, at the
location:
Declared XML Namespace(s):
Editorial comment:
http://docs.oasis-open.org/saf/ns/symptoms/2009/10
"... Don't think this is right, ie: the date..."
Responses:
The metadata field for the cover page with the
label "Declared XML Namespace(s):" is under TC Admin
control, as are all (meta) data elements on the cover
page, but here's one of the key considerations: a
"declared" XML namespace name involves the
syntax-appropriate use of a reserved family of
attributes which occurs in formal computer language
definitions, e.g., in XML schemas, in WSDLs, in XML
instances, etc. An namespace identifier is not
"declared" (per the standard) simply by saying so in
prose.
Note that formal computer language definitions, if
normative, need to be published in separate plain
text files, per TC Process.
Here are relevant pointers to namespaces (names,
bindings) which we use in the publication of
documents, and which we ask TCs to respect, as
a matter of standards compliance
http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#xml-namespaces
"OASIS Work Products which formally declare
http://www.w3.org/TR/2009/REC-xml-names-20091208/#dt-NSDecl
one or more XML namespaces [viz., namespace bindings]
must adhere to the terms of the applicable W3C
Recommendations (e.g., Namespaces in XML 1.0, Extensible
Markup Language (XML) 1.0, XML Schema) and several
OASIS rules for construction of URI references and for
use of namespace documents
http://www.w3.org/TR/webarch/#namespace-document
where applicable. XML namespace names are owned and
managed by individual OASIS TCs, based upon abbreviated
TC names, as specified below. Formal declarations of XML
namespaces are made using a family of reserved
attributes (e.g., xmlns attributes (PrefixedAttName
xmlns:[prefix] and DefaultAttName xmlns) and
targetNamespace) in XML instances and schemas.
http://www.w3.org/TR/2009/REC-xml-names-20091208/#concepts
http://www.w3.org/TR/REC-xml/
http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/#NS
The incorporation of a metadata element labeled
"Declared XML Namespace(s):" will be appropriate for the
specification if and when the the "Symptoms Automation
Framework (SAF) Cloud Profile" Work Product does formally
declare an XML namespace name according to the above rules.
In a hasty read, I didn't locate the required language
in prose which identifies/locates the machine-readable
files with the formal declarations, per TC Process:
http://www.oasis-open.org/policies-guidelines/tc-process#quality-formalLangDefns
"Computer Language Definitions. All normative computer
language definitions that are part of the Work Product,
such as XML instances, schemas and Java code, including
fragments of such, must be well formed and valid.
... All normative computer language definitions must be
provided in separate plain text files; Each text file
must be referenced from the Work Product [prose document]
We would expect (normative) computer language definitions in
separate plain-text machine-readable files where the
applicable XML constructs are used for formal declaration.
Examples, even if non-normative, would suffice.
==========================================================
3. Use of the Internet domain saf.com
==========================================================
The draft specification uses HTTP scheme URI references
for a number of identifiers (types, messages, etc). E.g.,
ClientID
HTTP response message
PrescriptionId
PrescriptionType
ProtocolReference
ProtocolType
Reporter
Subject
SymptomId
SyndromeType
http://saf.com/cimi/12345/machine/mymachine1
http://saf.com/prescriptions/001
http://saf.com/prescriptions/002
http://saf.com/reporters/systems_monitor-123
http://saf.com/subjects/service-12345
http://saf.com/symptoms/aggregate_cpu/12345/machines/1
http://saf.com/symptoms/salesprojection/1
http://saf.com/types/prescriptions/compute_provision_10
http://saf.com/types/prescriptions/compute_provision_5
http://saf.com/types/protocols/compute_provision_10
http://saf.com/types/protocols/compute_provision_5
http://saf.com/types/symptom/aggregate_cpu
http://saf.com/types/syndrome/combination/cpuload-salesincrease
http://saf.com/types/syndrome/cpuload
The use of such URI references with the HTTP scheme
is unobjectionable, but it is inappropriate for an
OASIS TC to craft identifiers based upon the Internet
domain "saf.com", evidently owned by the Southern
Aluminum Finishing Co. Inc (as reported by Netsol:
1581 Huber St NW, Atlanta, GA 30318-3781, USA).
Not only are the above URIs intrusive upon a domain
not owned by OASIS: their publication in an OASIS
specification could be the occasion for robot
analytics creating a penalty for the "saf.com"
domain, because the URIs are all 404'd.
If the SAF TC wants to use purely "example" URIs of
HTTP scheme for illustration, the domain "example.com"
may be used.
IANA: "Example Domains: As described in RFC 2606, we
maintain a number of domains such as EXAMPLE.COM
and EXAMPLE.ORG for documentation purposes. These
domains may be used as illustrative examples in
documents without prior coordination with us. They
are not available for registration."
If the SAF TC wants to create identifiers for types,
functions (etc) that are not purely examples, then
the base of a properly declared XML namespace name
may be used, per this instruction:
http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html#nonInformationResources
"Non-information resources using identifiers associated
with XML namespaces may be based upon any HTTP scheme
URI XML namespace declared by the TC (i.e., identifiers
for named properties, functions, dialects, faults,
actions, or any named message types). Example: see
the Link Relations URIs in one of the CMIS v1.0 XML
namespace documents [... refs follow]
For example:
http://docs.oasis-open.org/saf/ns/types/prescriptions/compute-provision
Cheers!
- Robin
On Mon, Mar 26, 2012 at 9:29 AM, Vaught, Jeffrey A <> wrote:
SAF-TC members,
We are close to completing the SAF cloud primer for DMTF-CIMI (Cloud Infrastructure Management Interface).
Please take a look and offer any final comments. We plan to distribute to the CIMI Co-Chairs later this week.
Thanks,
Jeff Vaught
SAF-TC Co-Chair
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
--
Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email:
Staff bio: http://www.oasis-open.org/people/staff/robin-cover
Cover Pages: http://xml.coverpages.org/
Newsletter: http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783
