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: [OASIS Issue Tracker] (OBIX-216) 14 Preformated vs Compaction


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

Craig Gemmill  updated OBIX-216:
--------------------------------

    Description: 
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). 

  was:
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 an way to use content negotiation to return a history query as CSV (or other pluggable formats). 


> 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)


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