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

 


Help: OASIS Mailing Lists Help | MarkMail Help

obix message

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


Subject: RE: [obix] Binary encoding (was: [obix] Groups -oBIX-1-1-spec-wd05.pdf uploaded)


1 - I would agree with this.    To my mind,  custom facets would be the most likely use case.   A custom object can be worked around using the 'is' facet in any event, so this change makes sense to me.   The only reason I had described support for objects was for completeness but it pained me to do it.
 
2 & 3 - Fair enough.
 
4 - Let me poke at this today; I think what you suggest works.
 
Thanks!
-Brad
 

From: Brian Frank [mailto:brian.tridium@gmail.com]
Sent: Friday, June 04, 2010 10:12 AM
To: Benson, Bradley
Cc: obix@lists.oasis-open.org
Subject: Re: [obix] Binary encoding (was: [obix] Groups - oBIX-1-1-spec-wd05.pdf uploaded)

First off, whatever changes Toby made seemed to have screwed up a lot of the formatting.  Most of the code sections got turned into bullet lists.

Couple thoughts regarding your proposal:

1.   it appears that maybe you are allowing extensions to be first class objects (elements) as well as facets (attributes)?  I would suggest we only allow extensions as facets (XML attributes), in which case we only have a facet code, not an object code.

2.  I would suggest we just keep the numbering in order and use 21 << 2

3.  I think we definitely want to encode the "name" using normal Str encoding so that it only has to be encoded once, then additional occurrences can reference previous offsets

4.  I haven't given it a lot of thought, but it would be nice if we could figure out how to leverage the existing codes for decoding the extension value so that implementation code doesn't have to have multiple code paths.  This is actually just a refinement of issue 3.  Maybe an extension is just followed by a string value and then an object value?


On Fri, Jun 4, 2010 at 9:57 AM, Benson, Bradley <BBenson@trane.com> wrote:
Easy enough - thanks!     I started with the most current doc from the documents section on the TC page and went from there.   Change tracking is enabled.  
 
The extension object type is certainly not as compact as what can be done with the standard encoding, but it allows extensions while being compatible i.e. not blowing up a parser that doesn't understand the details of a particular extension.    I did not make allowances for every data type currently supported, only primitives, string, and octet stream data.   I had considered adding all data types (time, etc.) but decided not to do so since this is by definition an extension and vendors may want to do their own thing anyway.  
 
Thanks!
Brad Benson
 
 
 

From: Benson, Bradley
Sent: Thursday, June 03, 2010 4:21 PM
To: Brian Frank Subject: RE: [obix] Binary encoding (was: [obix] Groups - oBIX-1-1-spec-wd05.pdf uploaded)

I'm gonna show some ignorance here and ask what the best way is to share the document with the proposed changes - is it best to just add to the documents section on the TC, attach to an e-mail, or some other method?
 
Thanks!
Brad Benson


From: Brian Frank [mailto:brian.tridium@gmail.com]
Sent: Wednesday, June 02, 2010 3:44 PM
To: Benson, Bradley
Cc: obix@lists.oasis-open.org
Subject: Re: [obix] Binary encoding (was: [obix] Groups - oBIX-1-1-spec-wd05.pdf uploaded)

I support that change.  I think the best way to move it forward it is propose suggested changes to the draft to specify how it would work.


On Wed, Jun 2, 2010 at 10:45 AM, Benson, Bradley <BBenson@trane.com> wrote:

The description of the binary encoding details specifically does not account for custom namespaces/elements/attributes as stated in section 8 para 2, which certainly seems reasonable.   However, it is wise to not provide a mechanism for such extensions to occur since they likely will anyway?    Conceptually, could we reserve a binary constant within the table in section 8.2 as a marker for a custom namespace/element/tag?      For example, binary constant 31 ( 31 << 2, using the notation in the aforementioned table) might be defined as the marker for a custom element or attribute, the name of which is encoded as a string immediately following the constant.     There are of course additional details to be worked here, but I think the concept is worth examining.

If there are no objections to this idea, I'd be happy to write up a more formal description as a proposal.

Side note - is it just my system or are several pages missing (or perhaps the table of contents is munged) - lines 259 through 285 within the TOC have undefined bookmarks, for example.

Thanks,
Brad Benson
Trane /Ingersoll Rand
bbenson@trane.com / 651-407-4285
"The way to get started is to quit talking and begin doing." - Walter Elias "Walt" Disney


-----Original Message-----
From: toby.considine@unc.edu [mailto:toby.considine@unc.edu]
Sent: Wednesday, June 02, 2010 8:39 AM
To: obix@lists.oasis-open.org
Subject: [obix] Groups - oBIX-1-1-spec-wd05.pdf uploaded

Several committee members have asked me about getting this to a standards vote soon - this will only happen with some participation and comments.

I have adopted a convention here that has proved useful in other TCs. There are multiple versions of this document. The most recent, or reference version, is a PDF with line numbers turned on. This makes for the easiest comments. An earlier version is a clean (changes accepted) word doc. To get to the earlier version, look at document properties in the libary, and see all versions.

In work going forward, I propose that we have an even earlier doc, that is a document with changes shown. This multi-versioon approach has helped focus and clarify work in other committees. The review copy with lines is a PDF because changes in printer can change line numbers....
This docum

 -- Toby Considine

The document revision named oBIX-1-1-spec-wd05.pdf has been submitted by Toby Considine to the OASIS Open Building Information Exchange (oBIX) TC document repository.  This document is revision #1 of oBIX-1-1-spec-wd05.doc.

Document Description:
Updated document to current template used for OASIS standards. For the most part, document was untouched, although I added references and acknowledgements.

There is now a blank chapter at the end for conformance statements. Current OASIS process dictates that the last normative chapter of a specification document must be conformance section.Appendices are for all non-normative material, i.e., background or explanatory. So far, I can't see a chapter to move in that direction.

View Document Details:
http://www.oasis-open.org/committees/document.php?document_id=38092

Download Document:
http://www.oasis-open.org/committees/download.php/38092/oBIX-1-1-spec-wd05.pdf

Revision:
This document is revision #1 of oBIX-1-1-spec-wd05.doc.  The document details page referenced above will show the complete revision history.


PLEASE NOTE:  If the above links do not work for you, your email application may be breaking the link into two pieces.  You may be able to copy and paste the entire link address into the address field of your web browser.

-OASIS Open Administration

The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php




The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.



The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.


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