RE: [obix] oBIX Guiding Principles

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: 

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