[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: potential language for Section 3 (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: FOUO In general I recommend avoiding self-referencing definitions. Object Model: generic definition of all oBIX entities and inheritance their relationships Extendibility and contracts seem redundant. Does Contracts not cover extendibility? The definition of encodings is good. -----Original Message----- From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Gemmill, Craig Sent: Tuesday, April 30, 2013 2:18 PM To: Considine, Toby; obix@lists.oasis-open.org Subject: [obix] RE: potential language for Section 3 I thought about that. I had thought that this statement was more to readers than implementers, but I guess you're right the implementers need to follow this too. From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Considine, Toby Sent: Tuesday, April 30, 2013 3:07 PM To: Gemmill, Craig; obix@lists.oasis-open.org Subject: [obix] RE: potential language for Section 3 Looks good. Consider appropriate use of SHALL (caps) when needed. ________________________________ "When one door closes, another opens; but we often look so long and so regretfully upon the closed door that we do not see the one which has opened for us." -- Alexander Graham Bell ________________________________ Toby Considine Chair, OASIS oBIX TC Editor, OASIS EMIX, Energy Interoperation Campus Services Information Technology University of North Carolina Chapel Hill, NC Email: Toby.Considine@ unc.edu <mailto:Toby.Considine@fac.unc.edu> Phone: (919)962-9073 http://www.oasis-open.org http://www.NewDaedalus.com From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Gemmill, Craig Sent: Tuesday, April 30, 2013 2:56 PM To: obix@lists.oasis-open.org Subject: [obix] potential language for Section 3 Obixers- I think we agreed to discuss on the email list for the language in section 3. I don't think much is needed, but in the interest of starting the discussion, How about simply: for the 'Architecture' section: Encoding: a set of rules for representing the object model in certain common formats. For the XML section 3.2 - retitled 'Encoding': A necessary facet of oBIX is set of simple syntax rules to represent the underlying object model. XML is a widely used language with well-defined and well-understood syntax that maps nicely to the oBIX object model. The rest of this document will use XML as the example encoding, because it is easily human-readable, and serves to clearly demonstrate the concepts presented. The syntax used shall be considered normative. Implementations using an XML encoding MUST conform to this syntax and representation of elements. When encoding oBIX objects in XML, eachoBIX is all about a simple XML syntax to represent its underlying object model. Each of the object types map to one type of element. Craig Classification: UNCLASSIFIED Caveats: FOUO
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]