[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix] RE: Changes in 1.1 spec draft - in scope? (UNCLASSIFIED)
So reiterating that things you say are *NOT* in for 1.1: 1) No means to query by tag. 2) Metainformation is offered if it exists 3) There is now to add metadata *Using* oBIX I think that a scope this limited is OK to include in 1.1. I think we need to add some support infrastructure. 1) What Tags do you use. URI for tagging standards? (“I can show you HayStack…”) 2) You have an implied Tag standard in your examples for “RoomNumber”. (I can tell you the Room Number”). Do we want to define that default? Do we want to add any other defaults? 3) It must be acceptable to have any number of meta-tags, including duplicates from the same space (Room202, Room202, Room203) Backwards compatibility. We do not want to confuse older systems. We do not want to force-feed a constrained protocol, COAP, say, with metatags that are unasked for. Request/Minimal Request/Full Request/Only Namespace=Haystack? Default is Request Minimal for backward compatibility? Going Forward: NBIMS/IFC based slices/semantics are simply another tagging standard Going forward: We should look at Queries in 2.x tc "If something is not worth doing, it`s not worth doing well " -- Peter Drucker
From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Gemmill, Craig 1. I haven’t described any mechanism for adding tags to the oBIX server via oBIX. I think simply reporting tags has value even without the ability to manipulate them, but I’m interested in what others think. If we need to add a way to add tags, that is probably done just by describing that it can be done using the same PUT/WRITE mechanism as for normal entities. 2. Query is not defined for other areas either, so not having it defined for this is not a big problem. I do think that adding/defining how query works should be a priority – it’s another part of making oBIX ‘useful’ as a model. 3. All part of how we define query. 4. … 5. Yes. IF your server wishes to report metadata, THEN this is how you do it. IF your server is a small sensor, you may not have the space to report tags, so fine. From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Toby Considine Re 8.5 Depends how deep we want to go. 1. Can I apply tags to point? Seems straight-forward. Do I do it through the oBIX interface or by some other means? 2. Can I query all points with a given tag to build my collection? Seems straightforward. Can I secure points by tag type? Not sure there. 3. If a tag is for a complex object, say a haystack an ahu with multiple ahurefs, can I query an ahu and ask for all refs? Can I query a point indicated by an ahu-ref be traced back to the ahu? Do we support complex queries such as “return all AHUs for which at least one of the AHUREFs is not a colddeck? How about AHUs associated with *this* chillerPlant but associated with any boilerPlant other than *that* How far down this road do we go? 4. How recursive are tag queries lets say we have an dischargeAirTempSensor associated with a discharge associated by AHUREF to an AHU associated with a chillerPlant. Can I query, through oBIX, all dischargeAirTempSensors associated with a chillerPlant? 5. Is a System that is otherwise 1.1 compliant but does not support tags conformant? I guess if adding tags is out of scope (1), then not being able to perform (1) causes no issues. If conformance is “able to query by tags if they exist” -----Original Message----- Classification: UNCLASSIFIED Caveats: FOUO My comments... 6.6.1: I'm not sure if this enhancement is worth breaking the 1.0 core since it is a requirement (to flatten the types). It seems like an issue better left to implementation or extensions. If we were going to include this in the 1.1 spec I would prefer dealing with it in a way that does not break the core "is/of/in/out" attributes. I would prefer adding an attribute(s) to accommodate ("inherits") flattening. How have others dealt with this issue? 8.5: This adds value, doesn't break 1.0, and I think it is fine for 1.1 scope. 13.1, 13.2, & 13.2.5: I think we should keep this. It adds a lot of value and solves some big headaches. If this had been around in the beginning I would've been a quicker adopter on some of my projects. Regards Chris -----Original Message----- From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Gemmill, Craig Sent: Thursday, May 30, 2013 12:14 PM Subject: [obix] Changes in 1.1 spec draft - in scope? All- Per discussion in our most recent meeting, I am notifying everyone about the latest draft of the 1.1 oBIX spec, and requesting comments on whether any of the proposed changes constitute too much of a scope change for 1.1, versus moving these changes into the upcoming 2.0 versions. The 2.0 version is intended not to be a core specification, but a collection of extensions to allow better enterprise interaction. So, with that in mind, the changes that are currently in the WD10, and which are under consideration for removing from 1.1 and moving to 2.0, are: * Compact contract flattening (6.6.1) * Enabling tagging/metadata presentation (8.5) * Alternate History formats via URI (13.1, 13.2) * Compact history records (13.2.5) Please take a look at the WD10 documents and comment to the list about whether you think these changes should be in-scope for the 1.1 version of the oBIX spec. Public URL for oBIX 1.1 wd10: https://www.oasis-open.org/committees/document.php?document_id=49119&wg_abbrev=obix Public URL for oBIX 1.1 wd10 (including change tracking): https://www.oasis-open.org/committees/document.php?document_id=49118&wg_abbrev=obix <https://www.oasis-open.org/committees/document.php?document_id=49118&wg_abbrev=obix> Thanks! Craig Classification: UNCLASSIFIED Caveats: FOUO --------------------------------------------------------------------- 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]