Fwd: User Hypermedia format

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