Re: User Hypermedia format

I'm concerned about verbosity of the messages as well as programmer time and experience. 

For example, I've been working with high resolution time series fitness data. Conceptually it's array like. There might be tens of samples per second of 1-10 different metrics, and 30 minutes is a typical duration. I'd like a format that just let me represent that part of a message as a compact first class array.

-- 
http://matthewlmcclure.com

> On Feb 28, 2014, at 11:58 AM, mike amundsen <[email protected]> wrote:
> 
> (copying back to the list)
> 
> all good Qs...
> 
> "How does the XML format represent true, false, and null?"
> ****
> so far, the approach i have is to treat this all as text data:
> <data transclude="false" />
> 
> it's possible to go further into this space using XML Schema, but I am not really interested in backing that into the format design. You could *definitely* use it by adding a <data url="..." rel="schema" /> element at the top of a representation. if that's what you want do to.
> ****
> 
> "How does the XML format represent objects and arrays? (Some sadist will put JSON in there unless we have a better answer.)"
> ****
> in XML there is no intrinsic Array pattern, just an implied one
> <data rel="collection" ...>
>   <data rel="item" ... />
>   <data rel="item" ... />
> </data>
> 
> is usually converted into an array in code.
> 
> JSON does this differently, of course by *requiring* explicit use of Array in the representation.
> ****
> 
> "More generally, I imagine your intent is to constrain clients to adopt more of a tolerant reader approach and use less automatic serialization and deserialization."
> ****
> bingo! ;)
> 
> my designs almost always attempt to downplay direct serialization into/from code. The trouble is programming languages can change over time and I'd like to make sure my designs don't favor (or become dependent) upon a sub-set of programming languages.
> ****
> 
> "At the same time, I think there's potential value in making compound, complex data more of a first class citizen. Allowing bare object and array data representations (not serialized into a quoted string) would let clients and servers reach inside the data without additional explicit deserialization steps."
> ****
> Keeping in mind what you describe here is a "programmer optimization" there are lots of ways to do this. We all got used to converting XML into code by way of "black box" functions in a language. We also got used to converting JSON into code in languages that didn't have the same internal structure as javascript. we did this w/ black box code. 
> 
> We can do the same with Uber (or any format, really). We need a DOM for that ,but it's not too hard; esp. with something like Uber that allows for recursion in the model.
> ****
> 
> "I guess one risk of allowing objects and arrays is the antipattern of using a single data element whose value is a very complex object."
> ****
> right, the killer is that messages become "envelopes" for code. this is what i am trying to avoid. I am trying to design format where messages are messages "all the way down" ;)
> 
> this means there is "heavy lifting" in creating the message (serialization) and parsing it for use ("de-serialization") and I want to keep that heavy lifting in code on each end - not in the message design itself.   For example the appeal of JSON is that there is "zero" lifting if you are writing javascript. However, that value dwindles as you get into other languages (erlang, python, etc.). 
> 
> "What are the tradeoffs you're trying to balance?"
> ****
> i'm experimenting here with ways to make it easier to express a wide range of use cases in a minimal format. and ways to make it easier to parse/validate the message regardless of platform or language.
> 
> in my Cj design i actually created a design that gave a bit "middle finger" to serializers everywhere<g>. i also tried to make to really hard to pass recursive messages by forcing a very flat structure in the message model.
> 
> with Uber, i am working on the other end of that set of values. i want to create a model that leads devs into creating recursive messages. but I am still working to thwart attempts to create code envelopes. Uber is a kind of "proxy" for objects on either end of the convo, not a "high-fidelity object tree tunnel" (if that makes any sense).
> 
> hope this helps and love to hear more from you on this.
> 
> 
> 
> mamund
> +1.859.757.1449
> skype: mca.amundsen
> http://amundsen.com/blog/
> http://twitter.com/mamund
> https://github.com/mamund
> http://linkedin.com/in/mamund
> 
> 
>> On Thu, Feb 27, 2014 at 1:40 PM, Matt McClure <[email protected]> wrote:
>> Mike,
>> 
>> 
>>> On Monday, February 24, 2014, mike amundsen <[email protected]> wrote:
>>> I've also added some text to the "value" definition to say JSON format MUST only be set to string, number, or literals (true, false, null) and MUST NOT be set to object or array. What is then implied (not yet stated in the prose) is that, to pass arrays or objects in the "value" attribute, you need to *escape* the object/array and pass as a string. 
>> 
>> How does the XML format represent true, false, and null?
>> 
>> How does the XML format represent objects and arrays? (Some sadist will put JSON in there unless we have a better answer.)
>> 
>> More generally, I imagine your intent is to constrain clients to adopt more of a tolerant reader approach and use less automatic serialization and deserialization.
>> 
>> At the same time, I think there's potential value in making compound, complex data more of a first class citizen. Allowing bare object and array data representations (not serialized into a quoted string) would let clients and servers reach inside the data without additional explicit deserialization steps.
>> 
>> I guess one risk of allowing objects and arrays is the antipattern of using a single data element whose value is a very complex object.
>> 
>> What are the tradeoffs you're trying to balance?
>> 
>> Matt
>> 
>> 
>> -- 
>> Matt McClure
>> http://matthewlmcclure.com
>> http://www.mapmyfitness.com/profile/matthewlmcclure
> 
> 
>