[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [saf] Cloud Primer
Thanks Robin. Great feedback on the issues. /chet On Tue, Mar 27, 2012 at 5:49 PM, Robin Cover <robin@oasis-open.org> wrote: > 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 -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn: http://linkd.in/OASISopen Twitter: http://twitter.com/OASISopen Facebook: http://facebook.com/oasis.open
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]