[OASIS Issue Tracker] (OBIX-216) 14 Preformated vs Compaction

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://tools.oasis-open.org/issues/browse/OBIX-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=37774#comment-37774 ] 

Toby Considine commented on OBIX-216:
-------------------------------------

I'm thinking of the post I shared with the TC this morning on EXI. 

One notion included that a schema-informed compression can be much greater than any standard compression. Does this suggest that referencing a scheme is part of the requirement here? Not fully baked thoughts:

1) There is a default telemetry schema. 
2) A request to track three things and report later creates, in effect, an alternate schema.
3) Either Schema is conformant with WS-Calendar streams.
4) Common schema encodings could include CSV
5) Alternate delimiters - could they be considered alternate encodings of the base schema?

Not sure where I am going here, but...





> 14 Preformated vs Compaction
> ----------------------------
>
>                 Key: OBIX-216
>                 URL: https://tools.oasis-open.org/issues/browse/OBIX-216
>             Project: OASIS Open Building Information Exchange (oBIX) TC
>          Issue Type: Improvement
>          Components: OBIX 1.1 Specification
>    Affects Versions: OBIX 1.1 XSD PR02
>         Environment: Brian Frank
>            Reporter: Toby Considine
>            Assignee: Craig Gemmill 
>
> 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.
>  
> So ideally we'd collapse all this into one new feature which is a way to use content negotiation to return a history query as CSV (or other pluggable formats). 



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)