[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [saf] Cloud Primer
Hi Robin, Thanks for your comments and corrections. We are reviewing them and making the necessary changes. Thanks and regards, Stavros From: saf@lists.oasis-open.org [mailto:saf@lists.oasis-open.org] On Behalf Of Robin Cover 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 = 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 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: There is no OASIS TC with identifier "symptoms" An XML namespace name identified by an HTTP scheme URI reference must conform to the pattern: 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 Please see the other instructions on XML namespace names in OASIS specs, and what is meant by "xxxx" above 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: "... 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 "OASIS Work Products which formally declare 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 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. 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: "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 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: "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: 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
-- This message w/attachments (message) is intended solely for the use of the intended recipient(s) and may contain information that is privileged, confidential or proprietary. If you are not an intended recipient, please notify the sender, and then please delete and destroy all copies and attachments, and be advised that any review or dissemination of, or the taking of any action in reliance on, the information contained in or attached to this message is prohibited. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Sender. Subject to applicable law, Sender may intercept, monitor, review and retain e-communications (EC) traveling through its networks/systems and may produce any such EC to regulators, law enforcement, in litigation and as required by law. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or free of errors or viruses. References to "Sender" are references to any subsidiary of Bank of America Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a Condition to Any Banking Service or Activity * Are Not Insured by Any Federal Government Agency. Attachments that are part of this EC may have additional important disclosures and disclaimers, which you should read. This message is subject to terms available at the following link: http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you consent to the foregoing. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]