Alps serialization - 'type' is a reserved keyword

[junosw]

Many languages today have libraries for serializing JSON to objects that can be used in code and back to JSON. One of the common patterns used is to write classes whose properties are then serialized to JSON where the property name would be the key in a typical JSON key/value pair.

Making use of these serialization libraries presents a problem when implementing serializers for ALPS because of the word 'type' that is used in the format. 'type' is a keyword in many languages and thus cannot be a property name of a class, breaking the use of serialization libraries that use the pattern described above.

I am facing this issue today and do not have a choice other than to either find a workaround to my serialization libraries or simply not follow the format (and use "type_" or something like that)

[mamund]

@junosw

good to see your note here.

not sure what it is you are doing, but this example project: https://github.com/alps-io/alps-contacts works with no problems.

can you be more specific on the errors you are encountering?

[mamund]

@junosw

I had a typo in my previous comment. i meant to point out the demo app in github here works just fine using the type attribute.

maybe you're doing something i can't envision yet. a sample would be great.

[junosw]

I'm using the Play Framework and writing Scala code using their JSON libraries which uses Jackson under the covers.

This is how I setup serialization for the Cj object:

https://github.com/junosw/samples/blob/master/Collection.scala

and this is how the Descriptor object would be setup:

https://github.com/junosw/samples/blob/master/Descriptor.scala

Note that the Descriptor case class cannot use the keyword 'type' as a property name. My assumption is that this same problem would arise for other languages when using a similar pattern for serialization.

[mamund]

@junosw:

ahh - so in scala "type" is a reserved word.

so how does scala handle XML Schema's "type" attribute?

[junosw]

Well, this isn't so much a problem with Scala as it is a problem with using the pattern where elements of a format map 1:1 to property names in classes. If there were an implementation available that made use of a classes properties in that way (where the XML 'type' attribute had an equivalent property in a class) then it wouldn't work. I haven't run across that yet but admittedly, I use XML far less than JSON.

This problem isn't unique to ALPS or Scala - it would be true of any format for any language where the semantics of the format mapped in some way to syntax used in the language and violated the rules of the language.

It just so happens that in this case, Scala + play's JSON serialization implementation + Alps meets the conditions. There are workarounds available I'm sure. But I have seen this serialization technique used before in other languages and with other formats - it is not uncommon. I believe .NET has some serialization libraries for XML that behave in a very similar way (although 'type' is not a reserved word in C#).

[mamund]

yeah - again, i understand you POV here, just wanting to get a better picture of the landscape. i suspect there are lots of languages with lots of reserved words and lots of messages that can creat conflicts. i am not prepared to take on the responsibility of making my design "reserved-word-proof" for all languages both existing and in the future.

the likely solution here is to stop trying to turn the ALPS type attribute into a first-class name in your code. why not treat it as a data value instead of a structural element?

[mamund]

@fosdev @fosrias

can you weigh in here. i know you're working on implementation details, too.

[junosw]

"i am not prepared to take on the responsibility of making my design "reserved-word-proof" for all languages both existing and in the future."

Yep, that would be impossible :) It might be beneficial to adoption of a format though to make sure that it isn't using keywords for some of the more popular languages out there now (I'm not saying that you are, just a thought).

That said, I thought that 'type' would be a reserved word in some of the more popular languages but looking into that as we are talking, I see that isn't the case :) Looks like Scala is special in that regard... oh well. Looks like I'll have to find a workaround for my implementation.

[fosdev]

@mamund @junosw Yeah, this is a good point. Whenever, I run into a naming collision with type, which happens every so often, I try to use kind. Means the same thing, but pretty sure it is much more robust among languages that of then have 'type' as a reserved keyword. So, it is worth considering, but frankly type is used for good reason in ALPS and elsewhere semantically imo.

i am not prepared to take on the responsibility of making my design "reserved-word-proof" for all languages both existing and in the future.

Will fail if you try.

the likely solution here is to stop trying to turn the ALPS type attribute into a first-class name in your code. why not treat it as a data value instead of a structural element?

I think you are right that libraries will have to accommodate these types of problems by just internally handling the collisions in a non-structural way. So, I would be open to kind, but though less than ideal, i think that ALPS dsls and libraries can locally solve this. And considering the myriad of possible nuances in libraries doing this, this would be a minor, albeit inconvenient, thing to accommodate, IMO.

[mamund]

@fosdev @junosw

do we think kind is a better term to use here?

[fosdev]

Pick your poison:

http://www.merriam-webster.com/dictionary/kind http://www.merriam-webster.com/dictionary/type

Fairly circular definitions. Frankly, I never really like using kind whenever I compromise and do it over type. I think type is better but could live with kind.

On Fri, Feb 28, 2014 at 12:24 PM, Mike Amundsen notifications@github.comwrote:

@fosdev https://github.com/fosdev @junosw https://github.com/junosw

do we think kind is a better term to use here?

Reply to this email directly or view it on GitHubhttps://github.com/alps-io/spec/issues/29#issuecomment-36390695 .

[mamund]

@fosdev: understood. @junosw: do you have any suggestions you want to make here?

maybe we just need to create a more explicit type ("semantic-type", "affordance", "affordance-type", etc.)?

[fosdev]

@mamaund Well, if you really wanted to simplify it, one option would be to get rid of type altogether and just use the values semantic, safe, idempotent, and unsafe as a descriptor keys like html 5 does with required in that it does not have a value and if present defaults to true. Not sure I like that, but may prefer that to getting more verbose over this issue.

On Fri, Feb 28, 2014 at 12:47 PM, Mike Amundsen notifications@github.comwrote:

@fosdev https://github.com/fosdev: understood. @junosw https://github.com/junosw: do you have any suggestions you want to make here?

maybe we just need to create a more explicit type ("semantic-type", "affordance", "affordance-type", etc.)?

Reply to this email directly or view it on GitHubhttps://github.com/alps-io/spec/issues/29#issuecomment-36392750 .

[junosw]

I agree that 'type' feels better than 'kind'.

I was also trying to think of additions to 'type' that would work... 'affordance-type' seems to work pretty well from a definition standpoint. It seems a little strange to the have the word 'semantic' included when that is one of the values.

[mamund]

i'd like to stay in NVP territory to make XML/JSON as interchangeable as possible.

atype stype at st t

[fosdev]

Well, as I said, wasn't sure i liked it :). Good point.

On Fri, Feb 28, 2014 at 12:54 PM, Mike Amundsen notifications@github.comwrote:

i'd like to stay in NVP territory to make XML/JSON as interchangeable as possible.

atype stype at st t

Reply to this email directly or view it on GitHubhttps://github.com/alps-io/spec/issues/29#issuecomment-36393431 .

[junosw]

I like atype and stype but would prefer atype - "affordance" makes a lot of sense here.

[fosrias]

So, are we talking:

If so, instead of intuitively mentally mapping `type` to 4 values, all which basically make ‘semantic' sense, we introduce 2 new abstract keys we have to mentally map and get the right values in. Worthy discussion, but KISS says how you did it originally @mamund is better IMO. On Feb 28, 2014, at 12:58 PM, junosw notifications@github.com wrote: > I like atype and stype but would prefer atype - "affordance" makes a lot of sense here. > > — > Reply to this email directly or view it on GitHub.

[junosw]

@fosrias

That was not what I was suggesting. I thought @mamund suggestion was to simply replace 'type' with 'atype' OR 'stype'. Not to use both, which I agree is worse

[fosrias]

Okay, then dtype (descriptor type) would make more sense to me, albeit more obscure than type, but we are defining a descriptor vs. an affordance.

On Feb 28, 2014, at 1:08 PM, junosw notifications@github.com wrote:

@fosrias

That was not what I was suggesting. I thought the suggestion was to simply replace 'type' with 'atype':

— Reply to this email directly or view it on GitHub.

[junosw]

I'm good with any letter of the alphabet since it will fix my serialization problem :) j/k

'dtype' makes sense too.

[mamund]

@fosrias: yeah, as @junosw said, just one change for all, not both 's' and 'a'.

and i could get behind dtype @junosw: that workable?

[fosrias]

Sure. @mamund T he thought struck me if we do this that for symmetry we might want to think about rt => retype even though you pulled ‘rt’ from an existing attribute elsewhere (can’t remember where), but rtype is more guessable for a human looking at this than rt.

Just a thought if we are cracking open the can of worms.

On Feb 28, 2014, at 1:17 PM, Mike Amundsen notifications@github.com wrote:

@fosrias: yeah, as @junosw said, just one change for all, not both 's' and 'a'.

and i could get behind dtype @junosw: that workable?

— Reply to this email directly or view it on GitHub.

[junosw]

@mamund absolutely

[fosrias]

typo. Meant rt => rtype On Feb 28, 2014, at 1:15 PM, junosw notifications@github.com wrote:

I'm good with any letter of the alphabet since it will fix my serialization problem :) j/k

'dtype' makes sense too.

— Reply to this email directly or view it on GitHub.

[mamund]

right rt or rtype to help w/ return type info.

i think it was just pushed back past first draft. i still like it, but IIRC @leonardr has some reservations.

FWIW, rt is what CoAP is using - that's where i got it.

so i'll update type to dtype and that should help us all out.

@junosw: thanks for bringing this up and sticking with it, too!

Cheers.

[junosw]

@mamund - absolutely! I really wasn't expecting this level of response and interaction but it's fantastic.

[mamund]

@junosw ;) we're a small but fiesty bunch.

honestly, @fosrias has been doing quite a bit of work trying to keep me on track. i'm trying to focus on ALPS right now and any/all input is very welcome.

thanks again.

[mamund]

ok @fosrias and @junosw

time to clear this up!

right now anything other than "type is going to be a breaking change. i'd like to avoid that and close this out.

any objections?

[fosrias]

@mamund was wondering about that. At this point I think we close this and leave it to ALPS client developers to accommodate this using some other convention. So, :+1: to close by me.

[mamund]

agreed.

closed w/o actoin.