RE: [obix] oBIX Guiding Principles

["Considine, Toby (Facilities Technology Office)" <Toby.Considine@fac.unc.edu>]

Anticipating some of the discussion, I am including the rationales for NO votes to date:

(I'm not sure how much of this is available to noninstitutional representatives from the voting pages)

 

====================================

 

BEA Systems votes no on UBL Naming and Design Rules v1.0 as an OASIS Standard. BEA commented during the public review that we believe that distributed extensibility and versioning is a key architectural component of distributed systems and UBL should allow for distributed extensibility [1]. The UBL TC responded to the effect that exchanging business documents where one side did not have the extension schema - what we have called distributed compatible extensibility - is not in business interests because both sides must understand any extensions for continued exchange. We believe that this requirement - that all parties in an exchange must simultaneously deploy new schemas and semantic understanding - is too onerous for business scenarios. There is a long history of compatible evolution of business documents that could be formalized and fostered by UBL. We are very concerned that this design will lead to very tightly coupled and brittle business systems. We are also concerned that this specification will act as an undesirable model for other specifications

 

====================================

 

SAP believes that the "Garden of Eden" approach used in UBL NDR, i.e. to use global element definitions only, is hard to implement and to maintain. The more flexible "Venetian Blind" approach, i.e. to allow local element definitions where appropriate, should be used instead.

 

(I believe we have already voted w/ SAP in our current draft)

 

 

 

 

---

From: Considine, Toby (Facilities Technology Office)
Sent: Friday, December 24, 2004 10:46 AM
To: obix@lists.oasis-open.org
Cc: 'jon.bosak@sun.com'
Subject: [obix] oBIX Guiding Principles

As a committee chair and institutional representative on OASIS, I get a lot of non-oBIX email from OASIS.  A lot of the email this month has to do with the Universal Businal Language (UBL) and more specifically, the UBL Naming and Design Rules (NDRs) specification which is up for a vote. Reading this document, which is very nicely crafted, has brought a few things in focus for me in regards to oBIX.

http://www.oasis-open.org/committees/download.php/9236/cd-UBL-NDR-1.0.pdf

A) As oBIX speaks to the Enterprise, rather than to other control systems, it is speaking to those who developed UBL. The UBL standard is interesting because it is has a less of a technical or "dweeby" audience than, say, UDDI or SAML, both of which have drafts this month. UBL is focussed on exchange of business information, not on securing or discovering that information. I think we should consider squinting at oBIX through the lense of UBL to see if we have got it right.

B) The UBL document leads with a statement of high-level principles that were used in the development of the standard (page 9). I think we should develop a similar statement for oBIX. For ease of consideration, I have included the UBL statement of principles here:

The UBL Technical Committee has approved a set of high-level guiding principles. The UBL Naming and Design Rules Subcommittee (NDRSC) has followed these high-level guiding principles for the design of UBL NDR. These UBL guiding principles are:

1. Internet Use - UBL shall be straightforwardly usable over the Internet.
2. Interchange and Application Use - UBL is intended for interchange and application use.
3. Tool Use and Support - The design of UBL will not make any assumptions about sophisticated tools for creation, management, storage, or presentation being available. The lowest common denominator for tools is incredibly low
   (for example, Notepad) and the variety of tools used is staggering. We do not see this situation changing in the near term.
4. Legibility - UBL documents should be human-readable and reasonably clear.
5. Simplicity - The design of UBL must be as simple as possible (but no simpler).
6. 80/20 Rule - The design of UBL should provide the 20% of features that accommodate 80% of the needs.
7. Component Reuse -The design of UBL document types should contain as many common features as possible. The nature of e-commerce transactions is to pass along information that gets incorporated into the next transaction down the line. For example, a purchase order contains information that will be copied into the purchase order response. This forms the basis of our need for a core library of reusable components. Reuse in this context is important, not only for the efficient development of software, but also for keeping audit trails.
8. Standardization - The number of ways to express the same information in a UBL document is to be kept as close to one as possible.
9. Domain Expertise - UBL will leverage expertise in a variety of domains through interaction with appropriate development efforts.
10. Customization and Maintenance - The design of UBL must facilitate customization and maintenance.
11. Context Sensitivity - The design of UBL must ensure that context-sensitive document types aren't precluded.
12. Prescriptiveness - UBL design will balance prescriptiveness in any single usage scenario with prescriptiveness across the breadth of usage scenarios supported. Having precise, tight content models and Datatypes is a good thing (and for this reason, we might want to advocate the creation of more document type "flavors" rather than less; see below). However, in an interchange format, it is often difficult to get the prescriptiveness that would be desired in any single usage scenario.
13. Content Orientation - Most UBL document types should be as "content-oriented" (as opposed to merely structural) as possible. Some document types, such as product catalogs, will likely have a place for structural material such as paragraphs, but these will be rare.
14. XML Technology - UBL design will avail itself of standard XML processing technology wherever possible (XML itself, XML Schema, XSLT, XPath, and so on). However, UBL will be cautious about basing decisions on "standards" (foundational or vocabulary) that are works in progress.
15. Relationship to Other Namespaces - UBL design will be cautious about making dependencies on other namespaces. UBL does not need to reuse existing namespaces wherever possible. For example, XHTML might be useful in catalogs and comments, but it brings its own kind of processing overhead, and if its use is not prescribed carefully it could harm our goals for content orientation as opposed to structural markup.
16. Legacy formats - UBL is not responsible for catering to legacy formats; companies (such as ERP vendors) can compete to come up with good solutions to permanent conversion. This is not to say that mappings to and from other XML dialects or non-XML legacy formats wouldn't be very valuable.
17. Relationship to xCBL - UBL will not be a strict subset of xCBL, nor will it be explicitly compatible with it in any way.

I think we could crib this almost exactly.  (15), (16) and (17) speak to some of the issues between oBIX and LON & BACNet. Aaron has rightly offered me the advice contained in (14) and (15) many times. (12) Translates nicely into our current conversations as to hoe many services should be in oBIX, i.e., just the three, or Power/HVAC/Monitoring/....

 

C) UBL-NDR states explicitly that they are using W3 XSD and why.

 

D) I find the use of terms Documents and Document Types noteworthy.  The term is correct, and can get lost when we are talking services and the like. Services sounds almost like we are maintaining interactive stateful protocols. Within SOAP, we are requesting delivery of XML documents. Each of our services is a document type. This may seem a small point, and mayhap noone else is prone to this confusion/elision other than me, but I feel compelled to note it.

 

------------------

The comments above relate to all of oBIX.  But the NDR is for the most part addressing the issues of creating new name spaces under the umbrella of UBL. In this sense, it is addressing the central issue we face when, once we have core services defined, we create new services for each control vertical.

 

E) UBL-NDR explicitly states its relationship to EBXML core components in section 3. I can imagine a similar document that offers guidelines on the development of new document types (services) and their relationships to the core services of oBIX.

 

 

F) We have gone back and forth on the subject of enumerated lists in oBIX. The UBL-NDR addresses this as follows:

UBL has determined that the best approach for code lists is to handle them as schema modules. In recognition of the fact that most code lists are maintained by external agencies, UBL has determined that if code list owners all used the same normative form schema module, all users of those code lists could avoid a significant level of code list maintenance. By having each code list owner develop, maintain, and make available via the internet their code lists using the same normative form schema, code list users would be spared the unnecessary and duplicative efforts required for incorporation in the form of enumeration of such code lists into Schema, and would subsequently avoid the maintenance of such enumerations since code lists are handled as imported schema modules rather than cumbersome enumerations.

I commend the entire Code discussion in section 6 (beginning on page 62)  to everyone's attention

 

G) If, as seem likely, this document is adopted as an OASIS standard, I recommend that we steal freely from this document, reusing as much as we can in our rules for developing subsidiary oBIX services as well as in the core document.  It is well written and defends its decison in a language that is focused and apropriate for the enterprise developer.

 

tc

 

 

---

"If you can't stand solitude, perhaps others find you boring as well."

-- Mark Twain

---

Toby Considine Facilities Technology Office University of North Carolina Chapel Hill, NC

Email: Toby.Considine@fac.unc.edu Phone: (919)962-9073