Maze+XML media type approved!
this is a follow up to my Registering A Media Type, Part I post from 2010-12.
i got good news last week. my application to the
IANA for registration of my
Maze+XML media type was approved! yep, it's
official; i am 'up on the big board'[grin]!
the details
completing the registation was very simple. the IANA has a short online form you can fill out and then it's all about waiting. and i did some serious waiting. turns out my application was part of a wave of IANA submissions at the end of the calendar year. while it usually only takes a couple weeks to get a response, i waited more than a month before getting the first feedback.
and i had made a few mistakes [sigh].
in fact, my pal @simonstl pre-saged my troubles. i had incorrectly handled some of the details of the XML type including parameters, security, and encoding. i was careless in filling out the form. i really needed to include almost the same text in each section (check the actual approved registration and you'll see what i mean).
but, after fixing up my errors, things sailed quite quickly. i recieved notice via email in about another week and viola! i am the proud papa of an officially reigstered MIME media type!
about Maze+XML
so, what's this media type all about, you might ask? well, assuming you did ask...
the Maze+XML media type was designed (as you can surmise from the name) to support client and server interactions for navigating through mazes or other "maps" or "games" that rely on "cell-by-cell" movement through a pre-dfine "play space." right now the media type supports simple navigation through a 2D space.
some other characteristics of this media type are worth noting. this particular media type is:
- Protocol Agnostic
- there is nothing in the media type documentation that requires a particular transport protocol (e.g. HTTP, FTP, etc.). while the current server implementation uses HTTP, other servers using other transfer protocols could be built as long as they support the "READ" semantics outlined in the documentation.
- Domain Specific
- the media type documentation includes a set of Link Relations specific to meeting the needs of a maze/map "application domain." there are indications of possible movement and of the location of the client within the maze. client applications can rely on (be coded for) these values to adequately express the "meaning" of links that appear in response representations. there are also a handful of domain-specific elements and attributes clients can look for and interpret along the way.
- Hypermedia Driven
- the only way to "advance the state of the application" is by activating hypermedia controls (links) in the response representations. client applications only need a starting URI and be able to locate, understand, and select hyperlinks in order to "play the game." this means any maze of any dimensions can devised by a compliant server can be presented to a complient client without the need to change existing client code.
- State Free
- this media type is also designed to work w/o requiring clients to track their own state values and transfer them back to the server for processing. IOW, there are no query variables or FORM|INPUT patterns for clients to deal with. all the interaction can be handled by activating simple outbound links. the media type, right now, runs perfectly fine in this "read-only" mode.
- Extensible
- the media type can be extended in the future. in fact, the functionality of the initial registration was purposely kept very limited in order to provide to experimentation with various strategies for safely extending media types that have already been deployed.
so what's next?
first, as you can tell from my above comments, the Maze+XML media type is in for some cool changes in the coming months. i hope to add optional features to support state-transfer operations (i.e. HTTP POST) and the ability of clients to optionally track their own state for various details of a "game."
i am particularly interested in the extension and modification of a deployed media type. luckily, several folks have already implemented "maze user agents" for this media type. it will be important to see how adding new features to the media type affects these already existing client applications.
BTW - i am still looking for some people to implement the server code for this media type. if you are interested in writing a "maze server," let me know.
you'll may have noticed that, so far, all the existing client implementations (except this one) are actually M2M clients; no human required! this is also very cool. however, will adding state-transfer and client state-tracking options make it impossible for 'bots' to play the games? we'll see...
the fun has just started
this is not the only media type design with which i have been experimenting. i have designs based on the JSON format. i have designs that are domain-agnostic (like HTML). and i have been working on media type designs based on the new semantic elements and attributes of HTML5.
since these are all experiments, i can't be sure how they will all turn out, but...