Re: [saf] Cloud Primer

[Robin Cover <robin@oasis-open.org>]

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 <Jeffrey.Vaught@ca.com> 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: saf-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: saf-help@lists.oasis-open.org

-- 
Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email: robin@oasis-open.org
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