The Atom Bidi Extension is a work in progress described by an IETF Internet-Draft. It is used to specify the base directionality of bidirection text within an Atom document.
When this text is displayed, the Unicode Bidirectional Algorithm needs to be used to display the text correctly. Unfortunately, Atom does not included a way of specifying the base directionality of text, which is why the bidi
attribute was created. See here for more information.
The BidiHelper class can then be used to properly render the text:
The BidiHelper class can also be used to discover the base directionality of text
If the dir attribute has not been set, the direction may be determined by applying a variety of guessing algorithms. Such algorithms are inherently flawed in that there is no reliable means of always guessing the right direction in every case.
When guessing the text direction based on the xml:lang value, the following rules apply:
- xml:lang values whose primary language tag is "ar","fa","ur","ps","syr","dv","he", or "yi" will always be Right-To-Left
- xml:lang values whose script tag is "arab","avst","hebr","hung","lydi","mand", "mani","mero","mong","nkoo","orkh","phlv", "phnx","samr","syrc","syre","syrj","syrn", "tfng", or "thaa" will always be Right-To-Left
- All other values are considered to have unspecified direction
When guessing the text direction based on the text properties, text strings that consist primarily of Right-To-Left characters will be assumed to be Right-To-Left.
When guessing the text direction based on the character encoding, the following encodings will always be considered as Right-To-Left: "iso-8859-6", "iso-8859-6-bidi", "iso-8859-6-i", "iso-ir-127", "ecma-114", "asmo-708", "arabic", "csisolatinarabic", "windows-1256", "ibm-864", "macarabic", "macfarsi", "iso-8859-8-i", "iso-8859-8-bidi", "windows-1255", "iso-8859-8", "ibm-862", "machebrew", "asmo-449", "iso-9036", "arabic7", "iso-ir-89", "csiso89asmo449", "iso-unicode-ibm-1264", "csunicodeibm1264", "iso_8859-8:1988", "iso-ir-138", "hebrew", "csisolatinhebrew", "iso-unicode-ibm-1265", "csunicodeibm1265", "cp862", "862", "cspc862latinhebrew"
The Atompub Features draft is a work-in-progress extension to the Atom Publishing Protocol Service document format that is used to describe the characteristics and behaviors implemented by a server implementation.
The API for working with the features extension is a work-in-progress.
Paging and Archiving
The Feed Paging and Archiving Extensions are defined by RFC 5005.
The FeedPagingHelper class can also be used to indicate whether a feed is a "complete" or "archive" feed
The Atom License Extension is defined by RFC 4946.
The Atom Threading Extensions are defined by RFC 4685
The GeoRSS extension allows geospatial data to be added to Atom entries.
Points, Lines and Polygons can be added to an entry.
Abdera supports a subset of the OpenSearch extensions
Abdera supports an experimental implementation of the MediaRSS extensions that can be used to add extended media metadata to an entry.
Abdera provides a limited implementation of the GooleLogin authentication scheme used by GData.
The example above has the downside of performing the GoogleLogin authentication on each request. The code below performs the authentication once and reuses it for each subsequent request.
Abdera also provides an implementation of the WSSE authentication mechanism
Abdera also provides a client implementation of the OAuth authorization scheme
Simple Sharing Extensions
Abdera supports an experimental implementation of the Simple Sharing Extensions. The following examples shows a minimal example of using SSE to merge entries from one feed into another.
The Sharing Extensions implementation also provides a means of resolving merge conflicts.
Abdera supports the ability to serialize Abdera objects out to a JSON representation. The JSON representation is documented here.