OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

chairs message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary

[If there is no normative content that why would Committee Notes have conformance clauses?]
Let me speculate along issues I have been wrestling with in this area to answer this...

I work in a variety of areas where there are developing concepts of something like profiles (overloaded term recognized) for areas that are not yet well understood. My domain space is still today heavily siloed, with the interactions just being explored. These areas smart buildings and smart energy are just beginning to creep into any sort of effective interactions. 

We defined a low level specification for an atomic interactions with control systems. These allow one to interact with embedded systems, for HVAC and for Security and for anything that is automated inside a commercial building or home or industrial site. (OASIS specification oBIX 1.0) These are just beginning to enable some more creative interactions, what I call the enterprise responsive building. 

Some of these interactions are high profile, such as all facilities in the 2008 Olympics, or all those surprising buildings in Dubai.  Some are intriguing combinations of IT and control systems, such as policy based event management of perimeter sensors used in Iraq. None of them are well defined enough, or repeated enough, or will any time soon get a mass of participants large enough to move to a standard.

Others might, but not yet. Interactions between Building Systems, and Open Floorplans , and Building Information for Emergency Responders (BIFER) might well rise to the level of standards, but not yet. The business models of smart energy, such as managed energy (direct load control) and collaborative energy, are so different from one another, and sometimes so different from today, that we do not see those making standards yet.

oBIX has a concept of Contract, something that binds a bunch of commands and requests together, and that can be referred to later as a unit, and that provides a lens for predefined views into a system. Today, each contract is hand-designed, and system specific. The oBIX work plan has long assumed that we would have standard contracts defined. The standard contracts do not belong in the oBIX specification, or do not yet. 

We have long been reaching for the right structure to define these standard contracts. This work would be interacting with the oBIX interfaces on the outside of diverse systems with diverse features and diverse underlying protocols. There may be competing oBIX smart energy contracts, for example, for some time. It has been difficult to guess where to put this type of work into the existing OASIS structures.

Perhaps these non-normative committee notes are the right way to define these contracts. 


"A man should never be ashamed to own that he has been in the wrong, which is but saying ... that he is wiser today than yesterday." -- Jonathan Swift

Toby Considine
Facilities Technology Office
University of North Carolina
Chapel Hill, NC
Email: Toby.Considine@ unc.edu
Phone: (919)962-9073 
blog: www.NewDaedalus.com

-----Original Message-----
From: Marc Goodner [mailto:mgoodner@microsoft.com] 
Sent: Friday, January 08, 2010 7:19 PM
To: Mason, Howard (UK); Anthony Nadalin; chairs@lists.oasis-open.org
Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary

If there is no normative content that why would Committee Notes have conformance clauses?

-----Original Message-----
From: Mason, Howard (UK) [mailto:Howard.Mason@baesystems.com]
Sent: Friday, January 08, 2010 4:05 PM
To: Anthony Nadalin; chairs@lists.oasis-open.org
Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary

I think this lower form of deliverable is exactly what "Committee Note"
is about.  It has no normative content, but provides useful explanatory information about the implementation of a specification or standard, and needs some form of agreement process.  "Guideline" is too specific - "note" is OK.  I guess the ISO equivalent would be a Technical Report.

Such a deliverable form would also cover the sort of gap analysis that is being proposed by the proposed "Identity in a cloud" TC, and which attracted an amount of negative comment because it was not a standard.

Howard Mason
Corporate IT Office
Tel: +44 1252 383129
Mob: +44 780 171 3340
Eml: howard.mason@baesystems.com
BAE Systems plc
Registered Office: 6 Carlton Gardens, London, SW1Y 5AD, UK Registered in England & Wales No: 1470151 

-----Original Message-----
From: Anthony Nadalin [mailto:tonynad@microsoft.com]
Sent: 08 January 2010 22:07
To: Don Day; chairs@lists.oasis-open.org
Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

Why not have a new document type below specification, I see this as trying to force fit and will open TCs up to all sorts of strange things that may not be appropriate 

-----Original Message-----
From: Don Day [mailto:dond@us.ibm.com]
Sent: Friday, January 08, 2010 2:01 PM
To: chairs@lists.oasis-open.org
Subject: RE: [chairs] Draft Jan 2009 TC Process changes summary

To side moreover with Ken and JoAnn,

The DITA TC has a number of subcommittees staffed by subject matter experts for domain-specific content. Some of their deliverables to the DITA TC which they have requested to be published within the DITA TC scope consists of best practices or guidelines for their respective communities, glossaries or term lists, and other collateral that goes with the use of the DITA Standard within the domain but which is not of the TC's interest to enshrine as part of the standard. We've recently had discussion within the TC about "non-normative" as a possible descriptor for such ancillary documents that fall in the scope of community-driven SCs to create, but are outside of the TC's direct charter. We are generally in favor of the process for an expedited but managed vetting process for such documents.

Don Day
Chair, OASIS DITA Technical Committee
Architect, Lightweight DITA Publishing Solutions
Email: dond@us.ibm.com
11501 Burnet Rd. MS9033E015, Austin TX 78758
Phone: +1 512-244-2868 (home office)

"Where is the wisdom we have lost in knowledge?
 Where is the knowledge we have lost in information?"
   --T.S. Eliot


  From:       "G. Ken Holman" <gkholman@CraneSoftwrights.com>


  To:         <chairs@lists.oasis-open.org>


  Date:       01/08/2010 03:34 PM


  Subject:    RE: [chairs] Draft  Jan 2009 TC Process changes summary


In the UBL TC not only do we have standards but also customization guidelines, naming and design rules, and other adjunct documents that help users work with the OASIS Universal Business Language.  These documents need the authority of the committee, but they don't specify anything that would be construed "a standard".

. . . . . . . . . . . Ken

At 2010-01-08 14:12 -0700, JoAnn Hackos wrote:
>Our Adoption TC is certainly interested. We are producing best 
>practices documents and other guides but no specifications.
>-----Original Message-----
>From: Mary McRae [mailto:mary.mcrae@oasis-open.org]
>Sent: Friday, January 08, 2010 1:31 PM
>   While you may not see it in any of the TCs you participate in, a 
>number of TCs are producing documents that they would like to have 
>approved (i.e. the TC is in agreement on the content of the document), 
>particularly in our Adoption TCs, but also by TCs wishing to produce 
>ancilliary documents such as a user's guide or best practices, or 
>possibly a white paper. It could also be a requirements document. The 
>list is far from exhaustive, which is why we have not tried to identify

>each and every possible type of artifact.
>On Jan 8, 2010, at 2:51 PM, Anthony Nadalin wrote:
> > I'm not aware of any requests to approve "things" that are not
>specifications, thus I question these chnages

UBL and Code List training:      Copenhagen, Denmark 2010-02-08/10
XSLT/XQuery/XPath training after http://XMLPrague.cz 2010-03-15/19
XSLT/XQuery/XPath training:   San Carlos, California 2010-04-26/30
Vote for your XML training:   http://www.CraneSoftwrights.com/o/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]