</snip>
great comment.
mapping ALPS semantic details to Cj message details is the "magic." we don't need to make Cj "look like" the internal model (e.g. the same nesting, object shapes, etc.). we only need to make Cj _carry_ the semantic details in a way that apps on each end (client and server) and consistently convert into their own internal models.
with this in mind, it is not important that the wire-level message have an actual "_property" section. but it IS important that both client and server can recognize that parts of the message that are the properties of an item. does that make sense?
one way to make this happen is to decorate the data elements with domain-specific information. for example, i can add a Cj extension which indicates the "type" of a single data element as "property":
now, generic clients can deal with this message just fine. at the same time, custom clients that recognize the internal concept of "property" can find the semantic details needed to construct a helpful internal model.
does this make sense?
WARNING: RANT AHEAD
Now, pardon me, while i rant on a bit. hopefully this will help you get the sense of what i think ALPS can do for us as we build widely dist apps.
IMO, a successful approach to creating systems that both offer wide support for generic clients AND provide a way to share domain-specific semantic details is to separate the internal model (objects, properties, relationships, etc.) from the external message (HTML, Cj, Siren, Atom, etc.).
the gap occurs when there is no common *bridge* between internal and external.
the most common way to attack this problem to date is to make the external *match* the internal model. IOW, object serialization. we do this every day. SOAP was based on this pattern (serialize object trees within a message envelope) and most all JSON-based services do this by offering custom objects on the wire via JSON nested hash-tables and arrays.
the challenge w/ exposing object models on the wire is that we all need to agree on the object model *before* we can write the apps.
ALPS is an alternate attempt at this problem of bridging internal and external models to close the gap
to do that, ALPS offers a way to consistently talk about the essence of the internal model (the data and actions) w/o actually forcing us to expose our internal object details. and ALPS is a _standardized_ way to do that. so that even generic clients that don't understand your internal model can understand the essence of that model.
formats like HTML, Cj, HAL, Atom, etc.) offer ways to consistently talk over the wire using a shared _external_ model. the format IS the model. this is proven to work well since HTML has been around for close to 25 years and we have a powerful (if not always perfect) generic client for it.
the challenge of message formats is that, the wider their applicability, the less domain-specific semantics are designed-in. and that's (again) where ALPS comes in.
i hope my ranting offers some useful info. thanks for the chance to bring it up ;)
cheers.