Below are my comments on current draft csprd02 (which I think is the latest)...
5.4.2 Encoding
Using a name attribute with a slash attribute conflicts with the recommendation characters which should be used in names. Simpler design would be just to have a list of strs:
<list name='encodings'>
<str val='text/xml'/>
<str val='application/json'/>
</list>
Sort of same problem for 5.4.3 - typically name is to identify the roll of the object within its parent, and names aren't typically used in lists. So seems better to make the binding name part of the value via 'val' attribute. Using the documentation URI as the value just seems like a lot of noise to me - I don't even understand what I'd put in there as a server, or why my client code would care about it. So I'd prefer simple list of str objects.
9.4 Alternate Hierarchies
There isn't any definition of what an alternate hierarchy actually means. Its a link to some other object, so why wouldn't any normal URI suffice? In what cases is the semicolon style URI required?
If this is the design for how to integrate Haystack tagging into oBIX, then it won't work well. Haystack takes a design approach that data and metadata is flattened into a simple associative array to model the entity. Therefore everything about the entity would be identified with one URI and object extent in oBIX. Instead the design should address how the notation of marker tags might be represented in the oBIX contract model (and/or extent). Discussion on haystack forum:
14.1 History Object (value metadata)
Experience with oBIX shows that we absolutely need all the history meta-data at this level. Today the only way to get this information is to actually make a query against the history data which is very inefficient, slow, and buggy. At the very least we need to know a) if history is number, boolean or enum and b) unit if numeric history. I'm sort of thinking the best way to tackle this is to have a prototype child object:
<obj href="">
<real name='valueProto' unit='obix:units/fahrenheit'/>
</obj>
Or we could potentially have an endValue that defined this (and was null if size was zero).
14.1 History Object (interpolation)
<obj href="">
<enum name='interpolate' val='cov'/>
</obj>
14 Preformated vs Compaction
It seems like two features have been introduced which essentially solve the same problem. If we define the ability to return history data using compact formats such as CSV, then why create another compaction model that still requires verbose XML with some new made-up plain text language? Some thoughts:
- the XML is largely the problem, so compacting within XML doesn't seem right direction
- omitting timestamps seems attractive, but seems very prone to data errors; my experience is that parsing a CSV file of 15min data for year is very fast (milliseconds) and with gzip encoding its hard to beat its size; so I do not think omitting timestamps makes sense - it will likely create huge number of bugs/bad data, and doesn't seem worth the trade-offs
- I think standardizing a simple CSV format with timestamp/values using a gzip transfer encoding is best overall solution
- the existing pre-formatted feature is awkward and doesn't really fit into the overall design of HTTP content negotiation. Plus it looks like it requires two requests to work right now.