add embed ext text

[mamund]

added "embed" as valid option for "render" param. for use when you want inline rendering, but are not linking to an image (i.e. HTML.IFRAME).

looking for feedback.

• should this (eventually) replace "image"?
• is this just 'cruft' and we can use "image" for all inline rendering?

[mamund]

if there are no comments on this one, i'll merge it in.

[camshaft]

@mamund How will the client know how to render it without further information of the content-type on the other end of the link? With the "render": "image" directive, the client knew that it was an image/* and could make some assumptions.

[mamund]

hmm.... good point! proly why i'd used "image" in the original design!

so, i suspect that the use of "embed" will also mean the need for a type
hint similar to the way HTML works, right?

{name: "content", value:"http://....", render:"embed",type:"text/plain"}

right?

mca+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

On Mon, Oct 22, 2012 at 12:18 PM, Cameron Bytheway <[email protected]

wrote:

@mamund https://github.com/mamund How will the client know how to
render it without further information of the content-type on the other end
of the link? With the "render": "image" directive, the client knew that it
was an image/* and could make some assumptions.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/8#issuecomment-9670130.

[camshaft]

Yeah I think that would be a good idea.

Would we then use the following for images?

{"name": "content", "value":"http://....", "render":"embed", "type":"image/png"}

[mamund]

yeah - that's the implication here. the optional use of "type" property on
any data element to help the client know how to augment/narrow the request
to the server for the URI in the "value" property.

mca+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

On Mon, Oct 22, 2012 at 12:38 PM, Cameron Bytheway <[email protected]

wrote:

Yeah I think that would be a good idea.

Would we then use the following for images?

{name: "content", value:"http://....", render:"embed",type:"image/png"}

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/8#issuecomment-9670984.

[camshaft]

Also would the type instruct the client to send "Accept: text/plain" when it makes the request? With that we could add some CR support to CJ.

[mamund]

yep - this is the outcome. adding "type" to data elements increases the CR
factor within the representation itself (other CR factors (i.e. the method
and format to use) are baked into the client based on the human readable
documentation.

mca+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

On Mon, Oct 22, 2012 at 12:45 PM, Cameron Bytheway <[email protected]

wrote:

Also would the type also instruct the client to send "Accept: text/plain"
when it makes the request? With that we could add some CRhttp://amundsen.com/hypermedia/hfactor/#crsupport to CJ.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/8#issuecomment-9671228.

[camshaft]

I'd be fine with this extension with the type field then. Not sure if there is any other feedback from others though.

[mamund]

frankly, i'm a bit hesitant to add more factors into this particular
design. i can see the value here, tho.

mca+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

On Mon, Oct 22, 2012 at 1:02 PM, Cameron Bytheway
[email protected]:

I'd be fine with this extension with the type field then. Not sure if
there is any other feedback from others though.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/8#issuecomment-9671835.

[camshaft]

I guess the only reason I can think of for not doing is overcomplicating the client/spec. I guess we'd have to decide if it's worth it.

[mamund]

yep - you're right on there.

i'd like to keep the parsing/computing complications at runtime relatively
low. this limits the "express-ability" (LOL) of reprsentations in CJ, but
increases the chances that an existing client will "recognize" and
"understand" CJ representations from artibrary servers.

however. as long as we keep the additions optional and as enhancements to
the existing design, it's relatively harmless. stuff that is not needed, is
too narrow, or just doesn't work well will be ignored and that's OK, too.

mca+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

On Mon, Oct 22, 2012 at 1:18 PM, Cameron Bytheway
[email protected]:

I guess the only reason I can think of for not doing is overcomplicating
the client/spec. I guess we'd have to decide if it's worth it.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/8#issuecomment-9672398.

[camshaft]

I think this is a pretty safe extension. The clients that don't recognize the embed directive will either simply show the link as, for example, HTML.A or not display it at all. The clients that do want to support it will become more complex however like you said more expressive.

[mamund]

yeah - this case is ok. i am speaking in general here, too.

keeping this particular design rather basic in regards to inline H-Factors
is a goal for me; that's the point of this design.

as long we that stys true, i'm cool w/ the extensions in general. a few of
the existing extensions go beyond that level for me and i don't think they
help much.

just sayin'

mca+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

On Mon, Oct 22, 2012 at 1:47 PM, Cameron Bytheway
[email protected]:

I think this is a pretty safe extension. The clients that don't recognize
the embed directive will either simply show the link as, for example,
HTML.A or not display it at all. The clients that do want to support it
will become more complex however like you said more expressive.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/8#issuecomment-9673409.

[vstirbu]

I'm doing some experiments having type as property of data and I welcome this addition to the spec, but in this case I think this example goes in the wrong direction:

{"name": "content", "value":"http://....", "render":"embed", "type":"image/png"}

it spreads what is basically a link information (like in Web Linking) over the value and type properties, when in fact that belongs to something like "value": {"href":"...", "type":"{mimetype}"... but now brings back the issue of representing more than flat structures with CJ... :)

[mamund]

it spreads what is basically a link information (like in Web Linking) over
the value and type properties, when in fact that belongs to something like
"value": {"href":"...", "type":"{mimetype}"... but now brings back the
issue of representing more than flat structures with CJ... :)

not sure i follow this. can you expand?

mca+1.859.757.1449
skype: mca.amundsen
http://amundsen.com/blog/
http://twitter.com/mamund
https://github.com/mamund
http://www.linkedin.com/in/mikeamundsen

On Thu, Oct 25, 2012 at 4:53 PM, Vlad Stirbu [email protected]:

I'm doing some experiments having type as property of data and I welcome
this addition to the spec, but in this case I think this example goes in
the wrong direction:

{"name": "content", "value":"http://....", "render":"embed",
"type":"image/png"}

it spreads what is basically a link information (like in Web Linking) over
the value and type properties, when in fact that belongs to something like
"value": {"href":"...", "type":"{mimetype}"... but now brings back the
issue of representing more than flat structures with CJ... :)

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/8#issuecomment-9793736.

[vstirbu]

I've spent the last days looking at geojson and json schema, and started to expect the "type" property to indicate the data type, either a simple type (e.g. string, number, array, boolean, etc) or complex types (e.g. Point or Polygon in geojson). So, yesterday (and quite late here) it felt odd to see a mimetype as the value of "type"...

Now that you know a bit more about the context when I made the comment, I still think that:

{"name": "content", "value":"http://....", "render":"embed", "type":"image/png"}

is an ad-hoc flattening of something that should look like:

{"name":"content", "value":{"href":"http://....", "type":"image/png"}}

Maybe I did not understood the problem too well, but looking at the other thread that discusses the inline-collection vs. your proposal in which the hierarchy is established with a "parent" property, I ended up not liking any!

So, is the extension proposal in this thread just a way to slip around the issue of being able to handle in a consistent way more than a flat k-v with CJ?

Vlad

[camshaft]

@vstirbu would "enctype": "image/png" be more appropriate?

[vstirbu]

not really. enctype describes the encoding of the data you send.

I think that a more appropriate way would be to change the valueto href, like this:

{"name": "content", "href":"http://....", "render":"embed", "type":"image/png"}

then valueshould mean embedded content while hrefis for external content...