Mappa.Mundi Index Go

Network Working GroupM.T. Rose
Internet-DraftInvisible Worlds, Inc.
Expires: September 7, 2000March 9, 2000

The Blocks Simple Exchange Profile
draft-mrose-blocks-exchange-01

Status of this Memo

This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except that the right to produce derivative works is not granted. (If this document becomes part of an IETF working group activity, then it will be brought into full compliance with Section 10 of RFC2026.)

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 7, 2000.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

Blocks[1] is an architecture for managing metadata. The architecture supports two models: the Blocks exchange model organizes information into navigation spaces, whilst the Blocks convergence model allows for bulk synchronization and knowledge management.

This memo describes the Simple Exchange Profile (SEP) used to exchange objects, termed blocks, residing in an SEP datastore.

To subscribe to the Blocks discussion list, send e-mail; there is also a developers' site.



Go

Table of Contents




Go

1. Introduction

In the Blocks Architecture[1], the Simple Exchange Profile (SEP) is used to exchange objects, termed blocks, residing in an SEP datastore.



Go

2. The SEP Datastore

An SEP datastore is a collection of blocks. A block can be viewed from two perspectives:

semantic:
a block is simply metadata about an external object; in this sense, an SEP datastore is not unlike a shared, distributed management system for documents;
syntactic:
a block is a unit of retrieval; in this sense, an SEP datastore is a collection of related XML documents[2].
The SEP is concerned with the latter perspective.

A block is a well-formed XML document that satisfies four constraints:

The first constraint allows each block to be unambiguously identified, whilst the remaining constraints make query optimization considerably easier to implement.

Blocks are expressed using either:

the generic syntax:
in which each property of the block is explicitly tagged using a "property" element; or,
the specific syntax:
in which a syntactic minimization technique is used to increase readability and reduce size.
The SEP datastore DTD defines the XML DTD used for the generic syntax of blocks stored in an SEP datastore. Note that although each block consists of a collection of structured properties, the unit of retrieval for the SEP is at the block-level. Applications making use of the SEP are free to further decompose the blocks exchanged.

2.1 Naming

Naming of blocks in an SEP datastore is hierarchical, with labels separated by slash, and read left-to-right, e.g.,

    net/ipv4/207.67.199.3
    doc/rfc/2629

A naming scope refers to the collection of blocks whose names are contained with a proper subtree, e.g.,

    doc/rfc/1006
    doc/rfc/2629

are both contained within the naming scope of "doc/rfc".

2.2 Data types

The SEP datastore DTD begins by specifying several data types for use when defining a block:

NAME:
Each block has a unique name. This datatype is used wherever the syntax of a name is required.
TYPE:
Each block consists of one or more properties. This datatype is used wherever the syntax for a property's type is required.
TYPES:
Sometimes it is convenient to refer to the types associated with a list of properties. This datatype is used for that purpose.
URI:
Although the attribute values associated with a property are textual, it is often useful to treat the character string as a higher-level construct. This datatype is used wherever the syntax for a URI[3] is required.
UINT16:
This data type is used wherever the syntax for a 16-bit unsigned integer value is required.
UINT32:
This data type is used wherever the syntax for a 32-bit unsigned integer value is required.
ATEXT:
This data type is used wherever the syntax for unstructured text in an attribute value is required.
CTEXT:
This data type is used wherever the syntax for single line, unstructured text is required.
TEXT:
This data type is used wherever the syntax for (potentially multiline) unstructured text is required.

2.3 Entities

At a minimum, each block must have a "name" attribute in its root element. In addition, each block may also have three optional attributes present in its root element:

serial:
an integer that is increased each time the block is updated;
ttl:
an integer, in seconds, that indicates how long this copy of the block should be considered authoritative; and,
creator:
a URI identifying the process that created or last updated this block.
Normally, these three attributes are supplied by the SEP datastore containing the block. The "%block.implied;" entity is used to denote these three optional attributes.

The "%block.attrs;" entity is used to denote the mandatory "name" attribute and these three optional attributes.

2.4 The Top-Level

Each block consists of the four attributes defined by "%block.attrs;", and zero or more "property" elements.

Each "property" element consists of:

Note that the ordering of "property" and "attribute" elements is not significant.

For example, consider:

    <block name="example/1">
        <property type="remote.props">
            <attribute key="uri"
                       value="http://example.com/scripts/1.tcl" />
            <attribute key="language" value="tcl" />
            <property type="title">An Example Script</property>
        </property>
    </block>

which is a block containing one property, called "remote.props". That property contains two attributes (one called "uri" and the other "language") and a subordinate property. The subordinate property, called "title", contains character data.

This example shows a block expressed using the generic syntax. Because XML elements may contain uniquely-named attributes, we can minimize the syntax:

    <xscript name="example/1">
        <remote.props uri="http://example.com/scripts/1.tcl"
                      language="tcl">
            <title>An Example Script</title>
        </remote.props>
    </xscript>

The rules to convert from the generic to the specific syntax are simple:

  1. Change the name of the top-level element from "block" to something else.
  2. For each "attribute" element subordinate to any "property" element: add the corresponding name/value pair as an attribute to that "property" element and remove the "attribute" element.
  3. For each "property" element contained within the block, change the name of that "property" element to the value of its corresponding "type" attribute and remove the "type" attribute from that element.



Go

3. Profile Identification and Initialization

Simple Exchange Profile Registration contains the registration for this profile.

The SEP is identified as

    http://xml.resource.org/profiles/SEP

Refer to [4]'s Section 2.1 for a discussion of the roles that a BXXP peer may perform, i.e., initiator ("I:") or listener ("L:"), and client ("C:") or server ("S:").

During channel creation, the corresponding "profile" element in the BXXP "start" element may contain a "request" element. If channel creation is successful, then before sending the corresponding "RSP" message, the BXXP peer processes the "request" element and includes the resulting "response" element in the "RSP" message, e.g.,

    C: REQ . 1 0 546 0
    C:
    C: <start number='1'>
    C:     <profile uri='http://xml.resource.org/profiles/SEP'>
    C:         <request reqno='1'>
    C:             <fetch>
    C:                 <union><intersect>
    C:                     <compare subtree='doc/rfc/2629'>
    C:                         <path attribute='name'>
    C:                             <element property='rfc' />
    C:                         </path>
    C:                         <value>doc.rfc.2629</value>
    C:                     </compare>
    C:                 </intersect></union>
    C:             </fetch>
    C:         </request>
    C:     </profile>
    C: </start>
    C: END
    S: RSP . 1 284 261 +
    S:
    S: <profile uri='http://xml.resource.org/profiles/SEP'>
    S:     <response reqno='1' serial='10' ttl='86400'
    S:               creator='bxxp://example.com/'>
    S:         <answers>
    S:             <rfc name='doc/rfc/2629' ... />
    S:         </answers>
    S:     </response>
    S: </profile>
    S: END

Note that it is possible for the channel to be created, but for the encapsulated operation to fail, e.g.,

    C: REQ . 1 0 531 0
    C:
    C: <start number='1'>
    C:     <profile uri='http://xml.resource.org/profiles/SEP'>
    C:         <request reqno='1'>
    C:             <fetch>
    C:                 <union><intersect>
    C:                     <compare subtree='doc/rfc/2629'>
    C:                         <path attribute='name'>
    C:                             <element />
    C:                         </path>
    C:                         <value>doc.rfc.2629</value>
    C:                     </compare>
    C:                 </intersect></union>
    C:             </fetch>
    C:         </request>
    C:     </profile>
    C: </start>
    C: END
    S: RSP . 1 284 267 +
    S: 
    S: <profile uri='http://xml.resource.org/profiles/SEP'>
    S:     <response reqno='1' serial='10' ttl='86400'
    S:               creator='bxxp://example.com/'>
    S:         <error code='501'>property attribute
    S: missing in &lt;element&gt; element</error>
    S:     </response>
    S: </profile>
    S: END

In this case, a positive "RSP" message is returned (as channel creation succeeded), but the encapsulated response contains an indication as to why the operation failed.



Go

4. Request and Response Messages

The Simple Exchange Profile DTD defines the messages that are used in the SEP:



Go

5. Message Semantics

The "request" element contains a "reqno" attribute and one of: a "fetch" element, a "notify" element, a "store" element, a "lock" element, or, a "release" element.

The "reqno" attribute (an integer in the range 0..4294967295) is used to correlate "request" elements sent by a BXXP peer acting in the client role with the "response" elements sent by a BXXP peer acting in the server role.

5.1 The Fetch Operation

The "fetch" element contains four attributes, a "union" element, and, optionally, an "ordering" element:

Each "compare" element contains three attributes, a "path" element, and a "value" element:

If the fetch operation is successful, then a "response" element containing an "answers" element, and optionally an "additional" element is returned as data in a positive "RSP" message; otherwise, a "response" element containing a BXXP "error" element (c.f., [4]'s Section 2.3.1.3) is returned as data in a negative "RSP" message.

If a "response" element is returned, then the order of blocks in the "answers" element are ordered from "most relevant" to "least relevant" (c.f., The Ordering Element). Accordingly, if all blocks satisfying the set-union are enumerated as a list starting at position 0, then the block at the position corresponding to the "offset" attribute is the first block returned in the "answers" element.

If a "response" element is returned, then the optional "actualNum" attribute may be present in the "answers" element. This attribute indicates the total number of matches for the corresponding "fetch" operation. If absent, the value of this attribute defaults to the number of blocks present in the "answers" element.

At the core of the fetch operation is the notion of a containment/value assertion. Each assertion identifies a comparison between a partial containment hierarchy and a textual value.

Several examples serve to illustrate these relationships.

First, consider:

    C: REQ . 1 546 345 1
    C:
    C: <request reqno='3'><fetch>
    C:     <union>
    C:         <intersect>
    C:             <compare subtree='doc/rfc' operator='contains'
    C:                      caseSensitive='false'>
    C:                 <path><element property='email' /></path>
    C:                 <value>mrose@</value>
    C:             </compare>
    C:         </intersect>
    C:     </union>
    C: </fetch></request>
    C: END

which looks for blocks satisfying several criteria: first, the block is named under "doc/rfc"; second, the block has at least one property called "email"; and, third, any of those properties contains the string "mrose@" somewhere within it, according to a case-insensitive comparison. Note that in this example, the "email" property may occur at any level of nesting within a block.

Second, a similar example:

    C: REQ . 2 891 266 1
    C:
    C: <request reqno='5'><fetch>
    C:     <union>
    C:         <intersect>
    C:             <compare subtree='doc/rfc'>
    C:                 <path attribute='surname' />
    C:                 <value>Rose</value>
    C:             </compare>
    C:         </intersect>
    C:     </union>
    C: </fetch></request>
    C: END

which looks for blocks in the same subtree, but is concerned only with attribute, not property, values. That is, if any property with a block has attribute called "surname" and the value of that attribute precisely matches the string "Rose", then this assertion succeeds. (Recall that the default value for "operator" is "eq" and the default value for "caseSensitive" is "true".)

Of course, if we wanted to limit containment of the attribute:

    C: REQ . 3 1157 344 1
    C:
    C: <request reqno='7'><fetch>
    C:     <union>
    C:         <intersect>
    C:             <compare subtree='doc/rfc'>
    C:                 <path attribute='surname'>
    C:                     <element property='doc.author' />
    C:                 </path>
    C:                 <value>Rose</value>
    C:             </compare>
    C:         </intersect>
    C:     </union>
    C: </fetch></request>
    C: END

which looks for blocks in the same subtree, but performs comparisons only on attributes called "surname" within a "doc.author" property.

In addition, if we wanted to further contain the attribute's property:

    C: REQ . 4 1501 501 1
    C:
    C: <request reqno='11'><fetch>
    C:     <union>
    C:         <intersect>
    C:             <compare subtree='doc/rfc'>
    C:                 <path attribute='surname'>
    C:                     <element property='rfc' />
    C:                     <element property='doc.props' />
    C:                     <element property='doc.front' />
    C:                     <element property='doc.author' />
    C:                 </path>
    C:                 <value>Rose</value>
    C:             </compare>
    C:         </intersect>
    C:     </union>
    C: </fetch></request>
    C: END

which looks for "doc.author" properties contained within a "doc.front" property contained within a "doc.props" property contained within a "rfc" property before looking at the "surname" attribute. Note however, that there is no concept of "rooting" in a containment hierarchy, e.g., in this example, the "rfc" property needn't be the top-level property of the block (i.e., the root element of the corresponding XML document).

Of course, an empty containment hierarchy is also possible, e.g.,

    C: REQ . 5 2002 247 1
    C:
    C: <request reqno='13'><fetch>
    C:     <union>
    C:         <intersect>
    C:             <compare subtree='doc/rfc'>
    C:                 <path />
    C:                 <value>Rose</value>
    C:             </compare>
    C:         </intersect>
    C:     </union>
    C: </fetch></request>
    C: END

which looks for the string "Rose" in any property. Similarly, to look for the string "Rose" in any attribute value, the containment "<path attribute='*' />" is used.

Note that in all the preceding examples, both the "union" and "intersect" elements had only one immediate subordinate, rendering each as the identity function. However, the presence of the elements is always required, regardless of whether their functionality is needed. To set-intersect the results of multiple assertions, the "intersect" element is given multiple subordinates, e.g.,

    C: REQ . 6 2249 494 1
    C:
    C: <request reqno='17'><fetch>
    C:     <union>
    C:         <intersect>
    C:             <compare subtree='doc/rfc' operator='contains'
    C:                      caseSensitive='false'>
    C:                 <path><element property='email' /></path>
    C:                 <value>mrose@</value>
    C:             </compare>
    C:             <compare subtree='doc/rfc'>
    C:                 <path attribute='surname' />
    C:                 <value>Rose</value>
    C:             </compare>
    C:         </intersect>
    C:     </union>
    C: </fetch></request>
    C: END

which evaluates two assertions and returns only those blocks satisfying both.

Similarly, to set-union the results of multiple intersections, the "union" element is given multiple subordinates, e.g.,

    C: REQ . 7 2743 537 1
    C:
    C: <request reqno='19'><fetch>
    C:     <union>
    C:         <intersect>
    C:             <compare subtree='doc/rfc' operator='contains'
    C:                      caseSensitive='false'>
    C:                 <path><element property='email' /></path>
    C:                 <value>mrose@</value>
    C:             </compare>
    C:         </intersect>
    C:         <intersect>
    C:             <compare subtree='doc/rfc'>
    C:                 <path attribute='surname' />
    C:                 <value>Rose</value>
    C:             </compare>
    C:         </intersect>
    C:     </union>
    C: </fetch></request>
    C: END

which evaluates two assertions and returns blocks that satisfy either. Of course, recursion is permissible between "union" and "intersect" elements, owing to their defintion.

5.1.1 The Related and MaxNum Attribute

Blocks satisfying the constraints of the "union" element are returned in the "response" element's "answers" element. These are termed satisfying blocks.

The "related" attribute, if present, causes blocks similar to the satisfying blocks to be returned in the "response" element's "additional" element. These are termed similar blocks.

A similar block is one that has the same value for any of related properties as any of the satisfying blocks. Note that when determining if a block is similar, the BXXP peer acting in the server role consults its entire SEP datastore -- a similar block may belong to an entirely different naming scope than any corresponding satisfying block.

Regardless, note that the "maxNum" attribute limits the actual number of blocks returned. As many satisfying blocks as possible must be returned; if the "maxNum" limit is not yet reached, then as many similar blocks within the limit may be returned. No additional constraints are placed on implementations if the value of the "maxNum" attribute is less than the number of satisfying and similar blocks.

5.1.2 The Ordering Element

If the "ordering" element is present in the "fetch" element, then this provides guidelines as to how blocks should be ordered in the "answers" element.

The "ordering" element contains one or more "path" elements, ordered as sort keys (i.e., the first "path" element is the primary sort key, the second "path" element, if any, is the secondary sort key, and so on). Each "path" element contains an "order" attribute indicating whether relevance is in ascending (the default) or descending order.

For example, to look for blocks containing a "surname" attribute of "Rose", and then order the blocks according to the value of their "doc.title" element:

    C: REQ . 8 3280 341 1
    C:
    C: <request reqno='21'><fetch>
    C:     <union>
    C:         <intersect>
    C:             <compare subtree='doc/rfc'>
    C:                 <path attribute='surname' />
    C:                 <value>Rose</value>
    C:             </compare>
    C:         </intersect>
    C:     </union>
    C:     <ordering>
    C:         <path><element property='doc.title' /></path>
    C:     </ordering>
    C: </fetch></request>
    C: END

5.1.3 The Notification, PrevStamp, and ReqStamp Attributes

If a fetch operation is successful and the "notification" attribute is "true", then it is referred to as a persistent fetch operation.

When performing the fetch operation, if the "notification" attribute is true, then the "prevStamp" attribute is also consulted. If empty, this indicates that the fetch operation is performed against the entire SEP datastore; otherwise, the value is identical to a previously returned value of the "reqStamp" in an "answers" element. In this latter case, the fetch operation returns an empty "answer" element with a "reqStamp" attribute value equal to the "prevStamp" attribute value, and all corresponding notify operations for this persistent fetch will contain information about changes that occurred after the "reqStamp" attribute value.

The fetch operation persists until either:

In the interim:

  1. The BXXP peer acting in the client role may not use the value of "reqno" in other requests.
  2. The BXXP peer acting in the server role periodically checks for changes to the blocks returned in the "answers" element in the original response. If so, a notify operation is generated.

Every "answers" element generated for a persistent fetch (contained in either a "response" or "notify" element) has a non-empty "reqStamp" attribute. This provides a mechanism to restart a persistent fetch operation after a connection loss: the BXXP peer acting in the client role records the most recent "reqStamp" attribute value whenever it sees an "answer" element corresponding to a persistent fetch. If the connection is lost (or the SEP channel is closed), then after re-establishing the connection and starting an SEP channel, the BXXP peer acting in the client role initiates a new persistent fetch by setting the "notification" attribute to true and the "prevStamp" attribute to the most recent "reqStamp" attribute value.

5.2 The Notify Operation

For each persistent fetch operation known to a BXXP acting in the server role, a periodic check is made for changes to the blocks returned in the "answers" element in the original response. If any of the blocks are changed or deleted, or, if new blocks are created that qualify as satisfying blocks for the original request, then a notify operation is sent.

The "notify" element consists of a "prevno" attribute, an "answers" element, and, optionally, either or both of a "additional" element and a "deletions" element:

Note that when constructing the "deletions" element, the blocks generic syntax may be used, e.g.,

    <notify prevno='45'>
        <answers reqStamp='3' ... />
        <deletions>
            <block name="doc/rfc/2629" />
        </deletions>
    </notify>

This strategy is useful if a server knows that a block was deleted, but the actual block is no longer available.

If the notify operation is successful, then a "response" element containing an empty "answers" element is returned as data in a positive "RSP" message; otherwise, a "response" element containing a BXXP "error" element (c.f., [4]'s Section 2.3.1.3) is returned as data in a negative "RSP" message. In the latter case, the fetch operation is no longer considered persistent.

Note that the BXXP peers switch server and client roles when going from a fetch operation to a notify operation, e.g.,

    I: REQ . 1 3280 88 1
    I:
    I: <request reqno='23'><fetch notification='true'>
    I:     <union ... />
    I: </fetch></request>
    I: END
    L: RSP . 1 284 57 +
    L: 
    L: <response reqno='23'>
    L:     <answers reqStamp='1' ... />
    L: </response>

    ... time elapses ...

    L: REQ . 1 341 83 1
    L:
    L: <request reqno='1'><notify prevno='23'>
    L:     <answers reqStamp='2' ... />
    L: </notify></request>
    L: END
    I: RSP . 1 3368 52 +
    I: 
    I: <response reqno='1'>
    I:     <answers />
    I: </response>
    I: END

5.3 The Store Operation

The store operation contains one attribute and one or more blocks to store.

In order to provide coordination between independent BXXP peers acting in the client role, a lock operation must be successfully performed before the store operation.

If the store operation is successful, then a "response" element containing an empty "answers" element is returned as data in a positive "RSP" message; otherwise, a "response" element containing a BXXP "error" element (c.f., [4]'s Section 2.3.1.3) is returned as data in a negative "RSP" message.

5.4 The Lock Operation

The lock operation contains one attribute:

If a lock operation is successful, then it is referred to as a persistent lock operation. It remains so until either:

In the last three cases, the BXXP peer acting in the server role should discard any journaled store operations for this channel. (Further, in the final case, the BXXP peer acting in the server role should also release the BXXP session with prejudice.)

In the interim:

  1. No other connection or channel may successfully lock within the subtree.
  2. No other connection or channel may successfully store within the subtree.
  3. Any store operations on this channel are journaled until a subsequent release operation.

If the lock operation is successful, then a "response" element containing an empty "answers" element is returned as data in a positive "RSP" message; otherwise, a "response" element containing a BXXP "error" element (c.f., [4]'s Section 2.3.1.3) is returned as data in a negative "RSP" message.

5.5 The Release Operation

The "release" element contains two attributes:

If the previous operation refers to a persistent lock operation, then the "action" attribute indicates whether the BXXP peer acting in the server role should either:

commit:
perform any journaled store operations for this channel; or,
rollback:
discard any journaled store operations for this channel.
Regardless, upon successful completion of the release operation, the corresponding fetch or lock operation is completed and no longer considered persistent.

If the release operation is successful, then a "response" element containing an empty "answers" element is returned as data in a positive "RSP" message; otherwise, a "response" element containing a BXXP "error" element (c.f., [4]'s Section 2.3.1.3) is returned as data in a negative "RSP" message.

5.6 Other Operations

If the BXXP peer receives a "request" element containing any other element, a "response" element containing a BXXP "error" element (c.f., [4]'s Section 2.3.1.3) is returned as data in a negative "RSP" message.



Go

6. Simple Exchange Profile Registration

Profile Identification:
http://xml.resource.org/profiles/SEP
Messages in Profile Initialization:
request
Messages in "REQ" frames:
request
Messages in positive "RSP" frames:
response
Messages in negative "RSP" frames:
error
Message Syntax:
c.f., The Simple Exchange Profile DTD
Message Semantics:
c.f., Message Semantics



Go

7. The SEP datastore DTD

<!--
  DTD for SEP datastore, as of 2000-03-03


  Copyright 1999, 2000 Invisible Worlds, Inc.

  This document is a DTD and is in full conformance with all
  provisions of Section 10 of RFC2026 except that the right to
  produce derivative works is not granted.


  Refer to this DTD as:

    <!ENTITY % DATASTORE PUBLIC "-//Blocks//DTD SEP DATASTORE//EN"
               "http://xml.resource.org/blocks/datastore.dtd">
    %DATASTORE;
  -->


<!--
  Contents

    Data types

    Entities

    Top-Level
  -->



















<!--
  Data types:

        entity        syntax/reference     example
        ======        ================     =======
    the name of a block
        NAME          ([A-Za-z0-9][-_A-Za-z0-9]*)
                          ("." ([A-Za-z0-9][-_A-Za-z0-9]*))*
                                           net.ipv4.207.67.199.3

    the name(s) of a property
        TYPE          [A-Za-z_][A-Za-z0-9_.]*
                                           ip.props
        TYPES         TYPE *(" " TYPE)     ip.props tcp.props

    pointers to resources
        URI          c.f., [RFC-2396]      http://invisible.net/

    integers
        UINT16       0..32767              42
        UINT32       0..4294967295         17

    unstructured text
        ATEXT                              "hello"
        CTEXT                              "Blocks server good to go"

    multiline character data
        TEXT
-->

<!ENTITY % NAME       "NMTOKEN">
<!ENTITY % TYPE       "NMTOKEN">
<!ENTITY % TYPES      "NMTOKENS">
<!ENTITY % URI        "CDATA">
<!ENTITY % UINT32     "CDATA">
<!ENTITY % UINT16     "CDATA">
<!ENTITY % ATEXT      "CDATA">
<!ENTITY % CTEXT      "#PCDATA">
<!ENTITY % TEXT       "#PCDATA">










<!--
  Entities

    entity            use
    ======            ===
    block.attrs       all blocks have these attributes

    block.implied     the subset of block.attrs that is usually
                      supplied in a containing element, e.g., SEP's
                      response element
  -->


<!ENTITY % block.implied " 
         serial       %UINT32;           #IMPLIED
         ttl          %UINT32;           #IMPLIED
         creator      %URI;              #IMPLIED">

<!ENTITY % block.attrs "
         name         %NAME;             #REQUIRED   
         %block.implied;">


<!-- 
  Top-Level
  -->


<!ELEMENT block       (property*)>
<!ATTLIST block
          %block.attrs;>

<!ELEMENT attribute   EMPTY> 
<!ATTLIST attribute
          key         %ATEXT;            #REQUIRED
          value       %ATEXT;            #REQUIRED>

<!--
  The content model defined below is a bit too general for us. The
  preferred content model is:

      (attribute*,(%TEXT;*|property*))
  -->

<!ELEMENT property    (%TEXT;|attribute|property)*>
<!ATTLIST property 
          type        %TYPE;             #REQUIRED>



Go

8. The Simple Exchange Profile DTD

<!--
  DTD for Simple Exchange Profile, as of 2000-03-03


  Copyright 1999, 2000 Invisible Worlds, Inc.

  This document is a DTD and is in full conformance with all
  provisions of Section 10 of RFC2026 except that the right to
  produce derivative works is not granted.


  Refer to this DTD as:

    <!ENTITY % SEP PUBLIC "-//Blocks//DTD SEP//EN" 
               "http://xml.resource.org/profiles/SEP/sep.dtd">
    %SEP;
  -->


<!--
  Contents

    DTD inclusion

    SEP messages
      The fetch operation
      The notify operation
      The store operation
      The lock operation
      The release operation
  -->


<!--
  DTD inclusion

    Caller should already have included the SEP datastore DTD.

    Caller should already have included the BXXP Channel Management
    DTD.

    Caller should already have defined %BLOCK; and %block.implied;
  -->




<!--
  SEP messages

     role           REQ                 RSP   
    ======          ===                 ===
    I or L          request             response
                                            +: (answers, additional?)
                                            -: error
  -->


<!ELEMENT request     (fetch|notify|store|lock|release)>
<!ATTLIST request
          reqno       %UINT32;           #REQUIRED>

<!ELEMENT response    ((answers,additional?)|error)>
<!ATTLIST response 
          reqno       %UINT32;           #REQUIRED
          %block.implied;>

<!ELEMENT answers     (%BLOCK;)*>
<!ATTLIST answers
          actualNum   %UINT16;           #IMPLIED
          reqStamp    %ATEXT;            "">

<!ELEMENT additional  (%BLOCK;)+>

<!ELEMENT fetch       (union,ordering?)>
<!ATTLIST fetch
          related     %TYPES;            #IMPLIED
          offset      %UINT16;           "0"
          maxNum      %UINT16;           #IMPLIED
          notification
                      (true|false)       "false"
          prevStamp   %ATEXT;            "">
<!ELEMENT union       (intersect+)>
<!ELEMENT intersect   ((union|compare)+)>

<!-- order attribute of path element is ignored -->
<!ELEMENT compare     (path, value)>
<!ATTLIST compare
          subtree     %NAME;             #REQUIRED
          operator    (eq|ne|contains|excludes)
                                         "eq"
          caseSensitive
                      (true|false)       "true"
          approximate (true|false)       "false">

<!ELEMENT ordering    (path+)>


<!ELEMENT path        (element*)>
<!ATTLIST path
          attribute   %ATEXT;            ""
          order       (ascending|descending)
                                         "ascending">
<!ELEMENT element     EMPTY>
<!ATTLIST element
          property    %TYPE;             #REQUIRED>
<!ELEMENT value       (%TEXT;)>


<!ELEMENT notify      ((answers,additional?,deletions?))>
<!ATTLIST notify
          prevno      %UINT32;           #REQUIRED>
<!ELEMENT deletions  (%BLOCK;)+>

<!ELEMENT store       (%BLOCK;)+>
<!ATTLIST store
          action      (create|write|update|delete)
                                         "write">

<!ELEMENT lock        EMPTY>
<!ATTLIST lock
          subtree     %NAME;             #REQUIRED>

<!ELEMENT release     EMPTY>
<!ATTLIST release
          prevno      %UINT32;           #REQUIRED
          action      (commit|rollback)  "commit">



Go

9. Security Considerations

The SEP is a profile of BXXP. In BXXP, transport security, user authentication, and data exchange are entirely orthogonal. Refer to [4]'s Section 8 for a discussion of these issues.



Go

References

[1] Rose, M.T. and C. Malamud, "Blocks: Architectural Precepts", draft-mrose-blocks-architecture-01 (work in progress), March 2000.
[2] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998.
[3] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[4] Rose, M.T., "The Blocks eXtensible eXchange Protocol", draft-mrose-blocks-protocol-01 (work in progress), March 2000.


Go

Author's Address

  Marshall T. Rose
  Invisible Worlds, Inc.
  1179 North McDowell Boulevard
  Petaluma, CA 94954-6559
  US
Phone:  +1 707 789 3700
EMail:  mrose@invisible.net
URI:  http://invisible.net/


Go

Appendix A. Acknowledgements

The author gratefully acknowledges the contributions of: Darren New.



Go

Appendix B. Changes from draft-mrose-blocks-exchange-00



Go

Full Copyright Statement

Acknowledgement

Mappa.Mundi Index Go