This document is for rough notes on pending changes and the reasons behind design decisions in Tablecast.
Motivations for switching from an element-based design to an attribute-based design:
Pending work item: Mention that although some JSON processors only support limited ranges of numbers (e.g. JavaScript only supports a 53-bit mantissa), the JSON syntax supports numbers of arbitrary size and Tablecast processors are expected to be fully compliant.
Pending work item: Use namespaced attributes, like "tc:effective" instead of "effective", so they can be attached to arbitrary other XML elements within XML-based content formats.
Attributes are now namespaced.
Added mention of the limited numeric range of some JSON processors.
Added recommended semantics for tc:row edits.
Changed recommended JSON format to GeoJSON for all geographic entities other than simple points.
Added limit query parameter to Tablecast service specification.
For snapshot view, switched from skip to skip-record
parameter.
There is interest in attaching other fields (such as name and e-mail address) to the author URI, but no solution yet. So far, Tablecast is using only a single URI for the author so that it can be used as a primary key representing an author. If two different clients mention the same author URI with different names, how should this be interpreted? Since we don't have a good answer to this, for now, Tablecast uses only the author URI.
The XML example doesn't validate at http://validator.w3.org/feed/
because the <feed> lacks a <title>
and the <author> lacks a <name>.
There should be a recommendation that field names should be ASCII C-style identifiers.
Consider removing <tc:deleted> in favour of explicitly nulling out each field, both to simplify the spec and to prevent publishers from deleting fields they don't know about.
There needs to be a way to detect history truncation, so that publishers don't have to keep history forever and subscribers can find out when they need to ask for a snapshot.