&info = {
name : string,
status_uri : uri
enroll_uri : uri
login_uri : uri
}
%% site_info << &info- abstract type system
-
as mentioned above, the abstract type system defines a core set of types and type behavior. types are intended to be "concretized" in programming languages like C, Java, Python, whatever. we create an "abstract" type system so we're free to define the type behavior we want while not being tied to type behavior of a particular implementation language. individual implementers are responsible for ensuring that type semantics are consistent with the spec.
for example, imagine you were developing an application using an embedded 8 bit microprocessor and there was a protocol flow that involved incrementing an integer. a client might send you a 32 bit integer, assuming you would increment it. you would be responsible for modeling the behavior of a 32 bit integer despite the fact your micro-controller probably only natively knows about 16 bit ints.
- abstract resource definition
the abstract resource definition is sort of like the abstract type system for collections. we define a resource as being either an individual item (a boolean, integer, etc.) or we define it as being a map or an array. the abstract resource definition system allows protocol developers to define the "shape" of resources. but because they are dynamic, implementations must allow for the type of a resource to differ from it's definition and for elements in map to be added and removed.
for example, you may want to define the following resource to describe an user logged into a system:
RESOURCE agent {
name string,
identifier uri,
current_location uri
}the abstract resource definition is used to group named data elements together into a dynamic structure. these structures will later be used by the abstract interaction definition.
- transfer syntax (aka serialization scheme)
-
these are basically the three serialization schemes defined in the type-system draft: XML, JSON and Binary. they define how structured data is serialized into an octet string in preparation for transmission across a network. for example, the resource defined above might be serialized like this:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE map PUBLIC
"+//IDN meadhbh.org//xxdsd 0.1//EN"
"http://home.meadhbh.org/xml/xxdsd/0.1/xxdsd.dtd">
<map>
<key>name</key>
<string>Meadhbh Oh</string>
<key>identifier</key>
<uri>http://world.secondlife.com/resident/6e7477a7-2de5-4660-bc83-4a47096a18f0</uri>
<key>current_location</key>
<uri>http://world.secondlife.com/place/65f385f0-691c-5755-9ef0-15f3bb05c8b7</uri>
</map> - abstract interaction definition
-
LLIDL currently defines access verb sets that are tied to HTTP verbs. if we want to be able to access resources using multiple transports, this is wrong. i propose we define an abstract interaction description "language" that is later mapped to a particular transport.
i propose we have five "abstract" verbs: CREATE, READ, UPDATE, DELETE and EVENT. the first four should be pretty straight forward. They're used to create resources, read and write them and then maybe delete them. the last verb, EVENT, is used to define a resource an entity may receive without requesting it. things like object updates, incoming message session requests, etc.
- transport mapping
-
the transport mapping maps abstract verbs from the abstract interaction description language to concretized protocol flows in the transport. so, for instance, you may use this to say that CREATE abstract access methods map to a POST verb in HTTP or that an EVENT message is delivered via the HTTP event queue.
