Getting Started
32 views
Skip to first unread message
David Layton
Jun 26, 2013, 6:29:22 AM6/26/13
to profile-...@googlegroups.com
I am looking to use ALPS in the system I am currently building. I get all the concepts, but I am would like some advise on implementation.
My project is greenfield, so any advise on where to start, libraries, specs, etc. is most welcomed.
Specifically, if anyone can point me towards profile and message examples (preferably in json) that would be great.
Before hearing about ALPS I was trying to implement something similar,
but I was try to just send around semantic triples which was unreadable and didn't solve the issue of legacy systems or really how to have a conversation
when required information for a service was specific to the instances provided.
mca
Jun 29, 2013, 10:08:01 PM6/29/13
to profile-...@googlegroups.com
David:
first, good to see you here! always nice to see new faces in this (very) small community (so far, anyway).
I know the docs/specs on ALPS are incredibly thin. that's due to two key things:
- this is all incredibly new
- i am slacking off on getting my work done and published here (<g>).
I'm working up a new spec doc[1] that will include quite a bit more preamble and background; that should help. And I'll include a bit of that here for starters. keep in mind that what follows below is very much a WIP (work in progress) and likely has lots of plot holes and faulty logic. things will get better as i work through this stuff, get feedback from you and others, post to the IETF working groups, etc.
Anyway, here are some additional points to consider:
*** Describing A Hypermedia Domain
One of the things ALPS is meant to accomplish is to describe a "hypermedia domain" without _proscribing_ implementation details. IOW, it's a higher-level abstraction. In fact, this abstraction is similar to the abstraction of Fielding's REST style[2]. Just as REST doesn't tell you _how_ to implement a single solution but instead describes the parameters used in creating solutions that share a similar style, ALPS doesn't tell you how to implement a single solution but instead describes the parameters used in creating solutions that share the same domain. See what I did there? REST==style, ALPS==domain.
*** Cross-Media Type Description
ALPS is also designed to describe this "hypermedia domain" in a way that is independent of any hypermedia type used to implement that domain. ALPS documents can be applied to HTML-based implementations, Atom, HAL, Cj, etc. In fact, another goal is that two implementations of the same problem domain (e.g. search, microblogging, etc.) that are based on the same ALPS profile document but implemented using different media types (e.g. HTML and Cj) SHOULD be inter-operable. IOW, if I had a client that understood both HTML and Cj AND understood the ALPS profile for "search", this client could successfully interact w/ a server that emitted HTML responses AND another server that emitted Cj responses as long as both servers ALSO relied upon the same ALPS "search" profile.
*** Cross-Protocol Description
Even more ambitious, ALPS is designed to describe "hypermedia domains" in a way that is independent of any protocol used to implement that domain, too. ALPS documents could be applied to HTTP, XMPP, WebSockets, etc. This means that a client that understood the ALPS "search" domain AND understood HTTP and XMPP could successfully interact with ALPS "search" servers that used these protocols, too.
*** Independent of Local Implementation Variances
Finally, ALPS profiles are designed to describe the "domain" of a problem, not the implementation of a solution for that problem domain. This means that ALPS documents create a bounding context around a domain problem, but don't specify what happens _inside_ that boundary. For example, the ALPS "search" profile could describe a handful of data elements (searchString, ResultsOrder, ResultsTitle, ResultsLink, ResultsDateTime) and a handful of hypermedia elements (searchLink, nextLink, previousLink, firstLink, lastLink, sortLink, etc.). however, ALPS does not describe what elements MUST appear within with resource, which input elements are REQUIRED, etc.
From the ALPS POV, it is sufficient to inform state machines (clients and servers) what possible data and hypermedia elements "live" within this domain and let specific implementors decide exactly which of these elements appear (if at all) at any given moment. For example, some implementations may not support sorting, some may not support paging, some may not return the DateTime of the link, etc. However, all state machines that comply with the ALPS "search" profile will be able to process these elements if and when they appear in any response. And they'll be able to continue to operate even when some of the elements are "missing" in some implementation.
*** Other Stuff
There are some other goals of the ALPS design including the ability to generate human-readable documentation, perform cralws and searches against existing ALPS profiles in order to find ones that cover a desired domain, incorporate aspects of existing specs (e.g. microFormats, ActivityStreams, schema.org, RDF ontologies, etc.) into a coherent description, and a few others. I'll leave the description of these aspects to another time.
I hope this brain dump helps. I hope it sparks more questions, too!
Feel free to post anytime here and keep me up-to-date on your work. Please use this as a place to send comments/suggestions/doubts, etc. on ALPS in general, too. I am wide open for suggestions on how to me this a useful and reasonable spec.
Cheers.
mca
--
You received this message because you are subscribed to the Google Groups "Application-Level Profile Semantics (ALPS)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to profile-semant...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Reply all
Reply to author
Forward
0 new messages