Federation Format

Intent

This standard further describes the Federation Protocol in terms of standard formats for "documents" to describe Waves.

This is a clarification of an existing standard.

Dependancies

Format

This standard describes the document formats in DTD, although strictly speaking DTD is not appropriate for documents are not XML. However they work satisfactorily for our purposes.

Terms

No special terms not explained in this standard's dependancies are required.

Authors/Reviewers

Manifast Documents

A manifast document, identified by the (optionally psuedo-) document id "conv", describes the layout of blip documents in a wavelet.

The structure of this document can be described with the following DTD:

<!ELEMENT conversation (blip*)> <!--If this wavelet is not inline, this element has no attributes--> <!ATTLIST conversation anchorWavelet CDATA <!--The waveletId that this is embedded in--> anchorManifastOffset CDATA <!--Integer representing offset into the parent's items--> anchorVersion CDATA <!--Integer representing the version of the parent when this wavelet was embedded--> anchorBlip CDATA <!--The id of the blip document in the parent wavelet this wavelet is embedded in--> anchorOffset CDATA <!--Integer representing the offset into the replied to blip that anchors this document--> > <!ELEMENT blip (thread*peer*)> <!ATTLIST blip id CDATA <!--The document id of the referred to blip--> deleted "1" <!--Has this blip been logically deleted. More efficient than deleting the whole blip from the document--> > <!ELEMENT thread (blip+)> <!ATTLIST thread id CDATA <!--Value uniquely identifies this thread--> inline "1" <!--Is this reply inline--> > <!ELEMENT peer #EMPTY> <!ATTLIST peer id CDATA> <!--The document id of the refered to peer-->

Blip documents

For illustration purposes, this DTD will have a root "blip" element. However, no item should be created for this element.

These documents describe blips in a wave, and the format can be described roughly with the DTD:

<:!ELEMENT blip (contributor+body!)> <!ELEMENT contributor #EMPTY> <!ATTLIST contributor name CDATA #REQUIRED> <!--The wave address of the described user--> <!ELEMENT body (line*file*reply*input*)> >!--Annotations on this tag are the tags on the wave.--> <!ELEMENT line #EMPTY> <!--Indicates the start of a line--> <!ATTLIST line t h1|h2|h3|h4|h5|li <!--The type of line, as in HTML--> i PCDATA <!--Integer representing the identation for type li--> a a|m|r|j <!--Alignment of text where a, m, r, and j are left, centered, right, and justified respectively--> d l|r <!--Text direction, left or right--> <!ELEMENT file #EMPTY> <!--Links in a attachment or gadget script--> <!ATTLIST file href CDATA <!--The URL for the file--> type CDATA <!--MIME type for the file.--> peer CDATA <!--If it is a gadget, identifies it's peer document--> > <!ELEMENT reply #EMPTY> <!--Positions an inline reply--> <!ATTLIST reply id PCDATA #REQUIRED> <!--The id of the positioned thread--> <!ELEMENT input #PCDATA> <!--As in HTML, validation can be done by robots--> <!ATTLIST input id CDATA #REQUIRED <!--Uniquely identifies an input--> type CDATA #REQUIRED <!--As in HTML--> >

Annotations

Annotations surrounding snippets of text should be preserved using Federation annotations. These are given meaning by Wave clients.

Peer Documents

Peer documents store data for gadgets, and contain a single textual item with annotations for gadget state.

User Documents

Within any Federation conversation, user documents should be accessable. These are stored like peers and are in the format "u+username!domain" taking the necessary information from Wave Addresses.

Standard annotations, provided by the user, are: