This is how we addressed these issues (and the related issue of Security, and the lack of it in the spec) in EMIX. Everything renumbers on the cut and paste,
but this was once 1.6-1.8. Note that this also defines conventions for the Schemas.
1.1
Naming Conventions
The names of EMIX XSD Elements and Attributes follow Lower Camel Case convention.
Example:
<element name="componentService" type="emix:ComponentServiceType"/>
The names of EMIX Types follow Upper Camel Case convention and Type names are postfixed with “Type“.
Example:
<complexType name="ComponentServiceType">
1.2
Editing Conventions
For readability, Element names in tables appear as separate words. In the Schemas, they follow the rules as described in Section 1.6.
Terms defined in this specification or used from specific cited references are capitalized; the same term not capitalized has its normal English meaning.
All sections explicitly noted as examples are informational and SHALL NOT be considered normative.
All UML and figures are illustrative and SHALL NOT be considered normative.
1.3
Security Approaches
EMIX will normally be conveyed in messages as part of business processes. Each business process will have its own security needs, including different consequences for failure of security. EMIX relies on the business processes using the
standard to ensure secure exchange of Price and Product information in energy market transactions.
"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
Finance & Administration IT
University of North Carolina
Chapel Hill, NC
Email:
Toby.Considine@ unc.edu
Phone: (919)962-9073
http://www.oasis-open.org
http://www.NewDaedalus.com
From: [mailto:]
On Behalf Of Considine, Toby
Sent: Thursday, September 26, 2013 9:00 AM
To: Craig Gemmill;
Subject: RE: [obix] Groups - OBIX-v1.1-WD14 uploaded
I believe in Section 1 there should be a small section on document conventions, perhaps section 1.6 (although it could be before 1.5)
The discussion of CamelCasing should move there from 5.
Discussion of document conventions, such as the different meaning of Object and object, Contract and contract, should be described therein.
tc
"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
Finance & Administration IT
University of North Carolina
Chapel Hill, NC
Email:
Toby.Considine@ unc.edu
Phone: (919)962-9073
http://www.oasis-open.org
http://www.NewDaedalus.com
From:
[mailto:]
On Behalf Of Craig Gemmill
Sent: Thursday, September 26, 2013 8:35 AM
To:
Subject: [obix] Groups - OBIX-v1.1-WD14 uploaded
Submitter's message
Here is a draft that contains the reorganization of Section 4. It also contains a start to the recommended changes in OBIX-30. I am interested in comments on the approach of using the term "Object" to represent the oBIX concept, and whether that is more or
less confusing. Should we also apply it to other concepts like Contract? Other candidates?
-- Mr. Craig Gemmill
Document Name:
OBIX-v1.1-WD14
Description
Intermediate working draft version of the spec showing sample approach to
some comments for TC discussion.
Download Latest Revision
Public Download Link
Submitter: Mr. Craig Gemmill
Group: OASIS Open Building Information Exchange (oBIX) TC
Folder: Standards
Date submitted: 2013-09-26 05:34:27
Revision: 1
