RE: [obix] oBIX Guiding Principles

Toby 
et al,

 

I 
would like to follow up on one item from your e-mail below :

 

"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."

 

I agree, and in reading this it brought a little 
different perspective to the current discussion between the power systems sub 
group and the XML sub group. The power system sub group delivered 
a description of 6 core services that we would be valuable for a power 
manament system to expose to an enterprise (i.e. request the profile of a 
particular load over the last week). 

After reading your comments above, it occured to me 
that we could really view this as a "report" request, with the report being 
customized by the requestor, or with an enterprise application picking out the 
pieces of the report that it is interested in. I don't know if this has bearing 
on our implementation decisions but it seems a better fit to 
me.

 

Rich 
Harwell 

 

  
-----Original Message-----
From: Considine, Toby (Facilities 
  Technology Office) [mailto:]
Sent: Friday, 
  December 24, 2004 9:46 AM
To: 
  
Cc: ''
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: 

    
      

      
Internet Use - UBL shall be 
      straightforwardly usable over the Internet. 

      

      
Interchange and Application Use - 
      UBL is intended for interchange and application use. 

      

      
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. 

      

      
Legibility - UBL documents should 
      be human-readable and reasonably clear. 

      

      
Simplicity - The design of UBL must 
      be as simple as possible (but no simpler).

      

      
80/20 Rule - The design of UBL 
      should provide the 20% of features that accommodate 80% of the 
      needs.

      

      
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. 
      

      

      
Standardization - The number of 
      ways to express the same information in a UBL document is to be kept as 
      close to one as possible.

      

      
Domain Expertise - UBL will 
      leverage expertise in a variety of domains through interaction with 
      appropriate development efforts.

      

      
Customization and Maintenance - The 
      design of UBL must facilitate customization and maintenance. 
      

      

      
Context Sensitivity - The design of 
      UBL must ensure that context-sensitive document types aren't precluded. 
      

      

      
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. 

      

      
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.

      

      
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. 

      

      
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. 

      

      
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.

      

      
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: 
Phone: 
        (919)962-9073