7. Notes and Issues

This is an editorial section that will be removed from the final version for notes, and issues pertaining to the protocol. Issues

  1. Transaction or fragment - fragment.
  2. How to do delete? - have the topic stub with no assocs or properties.
  3. Identity? - everything must have a PSI and a web address?
  4. How to stop topics being republished? - dunno yet.
  5. Fragment identifiers? - Assigned by the server?
  6. which version of xtm
  7. how to mandate a "good relation" between snapshot and change feeds
  8. how do we define compliance?

Things to look at:

  1. Atom publishing semantic. http://www.rfc-editor.org/rfc/rfc5023.txt

  2. Rdf syndication model payload. http://www.ietf.org/internet-drafts/draft-nottingham-atomtriples-00.txt This isn't interesting to us. Server responsibilities

  3. retrieve the current status of the topic map.
  4. Subscribe to a feed that lists all changed resources
  5. Subscribe to a feed that lists all topic map snapshots including the current status (see 1)
  6. For a given changed topic retrieve the fragment
  7. Parameterise the request to get a fragment
  8. Know if the listed topic has been deleted.
  9. Use src locators to indicate the properties of the topic to be replaced if they exist.
  10. The only srcloc that is published is a server specified one? How do we stop circular publication becoming a denial or service issue?
  11. Do we have topology layer?

A client node must

  1. Remember when it last updated its local map.
  2. Have configuration to specify what fragment structure to get.
  3. When updating a topic and that topic already exists to delete all properties in the srcloc namespace indicated by the fragment.

Service Ideas / URI Namespace

  1. /tmfeed - the topic maps feed /tmfeed/tmname - gets the feed for the named map /tmfeed/tmname?from=date
  2. /tmfragment/tmname/topics?id=topicid /tmfragment/tmname/topics?si=URI

egovpt_fg: CWA Part 1b Notes (last edited 2008-08-28 12:00:31 by MarcKüster)