establishing conversational context (was: Creating non-Atom LDPRs: AtomStrict & AtomRelax)

hello henry.

i am just responding briefly because i have work to do today. i like a lot
where you're taking this, but i'd like to respond in more detail to some
of the things you've been writing. most importantly, i'd like to stress
again that i always meant my comparisons with atom and atompub as looking
at design patterns. so we should try to learn from how they work (and
where they may be awkward), but of course we should use RDF's different
capabilities and metamodel.

On 2013-02-03 14:54 , "Henry Story" <> wrote:
><> a :Entry;
>   :title "My foaf profile";
>   :updated "2013-02-02T16:34:06Z"^^xsd:dateTime;
>   :author [ :name "Jack Daniels" ];
>   :content """
>     <> a foaf:PersonalProfileDocument;
>       foaf:primaryTopic <#i> .
>  <#i> a foaf:Person;
>     foaf:name "Jack Daniels";
>     foaf:interest <>;
>     foaf:knows <>,
>                <> .
>  [] a <> ;
>     likes <#i>, <> .
>  """^^^xxx:Turtle .
>Here we only have 1 syntax but we still have the data and the
>metadata as two seperate contents.

thanks for spelling this out. you make good points why we don't want this,
and i think if there's one thing that's a very well-established
anti-pattern in protocol design, it's escaped markup. it's terrible to
handle, brittle, processing model hell, and even worse in multi-syntax
environments such as RDF.

however, why did we end up with this unfortunate example? because in this
case, only escaping, as you mention, allows us to separate protocol data
and content. we can avoid getting in this mess by setting conversational
context via media types, ideally (sorry for repeating this) by actually
using a protocol media type, or by using profiles for augmenting the
generic RDF media type identifiers.

why am i repeating this: it's the problem we started with in many
different places quite a while ago: how can i distinguish between just
putting LDP triples in an entry's content, or adding LDP data. in atom,
this all works perfectly just because of media types. for example, if you
have a collection that exposes application/atom+xml and application/xml,
then this is exactly and all you need. you can do these two things:

POST collection
Content-Type: application/atom+xml
<entry> .... </entry>

POST collection
Content-Type: application/xml
<entry> .... </entry>

and they do different things, because of the media type. in the first
case, we use the protocol to send a request about creating an entry with
some metadata and probably content in it. fine, this will become an
"aggregate" member.

in the second case, we use the protocol to ask the LDP service to please
create a new XML resource with opaque XML in it, and the entry we're
POSTing will just be the content of the newly created member (it will
become a "media resource"). in the second case, LDP will create an <entry>
by itself, and redirect us to it, so that in the end we have created two
entries with one POST: the LDP member that is the entry created by LDP
itself, and the <entry> markup that we have POSTed that is treated by LDP
as being opaque XML.

and that's not all: in the second case, i'll end up with two URIs: let's
call them collection/member/42 for the LDP entry created by the LDP
service, and collection/member/42/content for the XML that i have POSTed.
i can GET both of them, and i can send the URIs of both of them to
anybody. again, media types make this work robustly:

- when GETting collection/member/42, the server responds with a
application/atom+xml resource, making it clear that this is not just XML
that happens to look like atom, it is actually a resource that promises to
follow the rules of the conversational context of atom. thus i can start
processing the contents as atom: i use atom's processing model and
protocol. in that entry, you,ll find a link to the entry's content at

- when getting collection/member/42/content, the server responds with a
application/xml resource, making it clear that it's serving XML that's
payload (a media resource) and not protocol, so clients shouldn't use
atom's processing model and protocol to interpret it. you could look at
this like it's "escaped by media type", the generic media type makes it
clear that this resource (as it's being served from this server) has no
web-level behavior associated with it, it's just XML data. a media  tyoe
is a promise to follow rules, and for this resource, the atom server does
not promise to follow any rules, because the XML could by anything and the
server neither knows nor cares.

last but not least: because of these clear rules, it is logically
impossible to POST something that is labeled as application/atom+xml but
does not follow the media type rules. said differently, you cannot have a
collection that accepts application/atom+xml as media resources: if you
want to build an atompub server managing XML, it has to expose other XML
media types that that, either specific ones, or the generic

i know that i am mostly reiterating things here, but i am hoping that we
are at a point now where these things make more sense, because of the
issues we run into with our protocol design. i do believe that when
designing protocols, being able to clearly establish conversational
context is essential. how we do it is something we still need to discuss,
but for now all i want to say strongly is that we definitely should avoid
escaped markup. but i think we all agree on that one anyway ;-:



Received on Monday, 4 February 2013 07:58:23 UTC