OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: [xml-dev] Ted Nelson's "XML is Evil"

[ Lists Home | Date Index | Thread Index ]


Jonathan Robie wrote:
> 
> What's the silver bullet? What's going to drive people away from the
> HTML and XML systems that are good enough for 90% of what people need?
> What is it going to drive them to?


Universal State Transfer?  :-)  Only they ain't no
transclu-whatsit in this, and they ain't gonna be:


Context Transfer Protocol (Uniform Context Transfer Protocol?)

The context transfer protocol (CTP) is an end-to-end data
transport  protocol that supports manipulable distributed
hypermedia and data  processing on the basis of the concept of
universal state transfer. It  employs a set of abstract terms
that designate the elements of a  uniform structure for
representing and transferring state, called the  uniform context
framework (UCF). 

In place of documents and files, CTP implements contexts,
manipulable  collections of resource elements which are referred
to according to the  UCF abstractions. All of the elements of a
context are assigned key  values which function as links to the
servers at which the elements  originate. Because all elements
are links, multiple contexts may freely  reuse the same elements. 

The elements of the UCF reflect a universal information
architecture  which supports all the fundamental operations one
needs for managing  information, including modeling, updating and
maintenance,  manipulation, querying, categorizing, distribution
and dependency  tracking. In this way, CTP implements the notion
of an atomic  application. Fundamental information processing
functions for any  application can be implemented simply by
declaring a CTP context, or by  declaring multiple contexts to be
combined in a complex application.  Any CTP front end interface
that surfaces the full complement of CTP  functionality can be
used to browse and work with any information for  any other
application served by a CTP server. 

CTP is designed for scalability, providing a simple uniform
interface  through the use of a small set of verbs (GET, PUT,
REMOVE and HOST) and  the finite set of generic elements which
make up the UCF. CTP servers  attain the status of universal
application servers in the sense that  all fundamental
information management functions are provided by means  of this
interface and the rest of the functions and architecture 
incorporated within the protocol. 

The information architecture underlying CTP affords a maximum
degree of  flexibility in data processing. Entity relationships
for all  applications are stored in a flat fact table form,
allowing information  to be accessed and worked with rapidly,
flexibly and with implicit  interoperability among all
applications. In addition, by using the UCF  abstractions as
generic primitives, CTP makes possible a highly  granular
procedural approach to data processing that is unimpeded by  the
intricacies of entity-relationship models or the strictures of 
table- or record-level distribution and/or replication.
Higher-level  techniques for managing complexity, such as
set-oriented and object- oriented data processing and
programming, may be implemented on top of  the CTP layer. 

Instead of working with information through the representation
of  diverse entities in separate physical tables, the CTP
physical data  model is a generalized and denormalized structure
that directly  represents relations as such. Relations
implemented under CTP are  called contexts. CTP uses the
following generic abstractions to  represent the elements of any
context: 

Space 
Location 
Standpoint 
Use Type 
Use 
Link Type 
Link 
Use Attribute 
Link Attribute 
Use Attribute Value 
Link Attribute Value 
Use Category 
Link Category 
Use Category Value 
Link Category Value 


These elements make up the uniform context framework (UCF), a
standard  structure for representing and transferring state. CTP
assigns unique  key values to each element, made up of a URL
(designating the location  of a CTP server), a forward slash, and
a key value unique to that  server. For example:
ctphome.org/18273645. 

A general context in CTP is comprised of a use type related to a
link  type. A particular context instance is designated by a
particular use  of the use type, which can have any number of
links, particular  instances of the link type, related to it.
This combination of use  types, link types, uses, and links
describes a traditional one-to-many  relationship, wherein the
various uses of a use type serve as “records”  of the parent
entity type (on the “one” side), and the multiple links  of a
link type serve as “records” of the child entity type (on  the
“many” side). 

In CTP, state is an aspect of contexts representing their
generality,  and is designated in terms of the concepts of space,
location, and  standpoint. Declaring a state for a CTP context
means that the context  serves as a convention among all clients
and servers that participate  in that state. Space represents the
notion of an abstract realm within  which numerous CTP servers
participate and interoperate as they support  shared contexts.
Location represents an individual CTP server.  Standpoint is an
abstraction used to represent states of narrow scope  hosted at
particular locations, for the purpose of independent or 
provisional development work. 

Generality of a state is designated by either providing key
values for  space, location and/or standpoint, or leaving their
key values empty. A  state representing generality across an
entire space is represented by  providing a unique key value for
the space, while leaving the location  and standpoint keys empty. 

A state for representing universal conventions would be
designated by  leaving all three key values empty. However, since
this designates no  authoritative server for the state, contexts
defined within such a  state cannot be managed by CTP, and would
require ratification as  standards by external standards bodies,
followed by general adoption in  code and practice. With CTP,
this process of fostering general adoption  by means of standards
bodies becomes significantly less necessary.  Instead of
presupposing that state and physical data models are so 
arbitrarily complex and diverse as to necessitate such a process
in  order to assure interoperability, CTP provides for universal 
interoperability at the data transport level. 

Traditional entity-relationship modeling entails record- and
table- level replication in distributed environments because it
binds sets of  attributes to individual physical tables
representing discrete  entities. Under CTP, distribution of
attributes and their values is not  accomplished in the same
manner. CTP uses the UCF to distribute  metadata describing the
relational organization of information across  servers, while it
leaves particular attribute values at particular  locations,
where CTP servers act as their authoritative hosts. User  agents
and interoperating CTP servers may maintain the currency of 
their local caches of attribute values according to any
algorithm  appropriate to their own purposes. 

Instead of binding sets of attributes to particular tables
representing  particular entities, CTP uses the abstractions that
make up the UCF to  describe scopes of relevance for link and use
attributes. Attributes  can be declared to be relevant for all
links of a particular link type,  or for all links used by a
particular use type, or for all instances of  a particular use or
link regardless of general context (use type and/or  link type),
or for any other of the finite number of scopes that can be 
described by the possible permutations of the UCF elements. CTP
servers  provide and maintain appropriate attributes and values
for various  contexts according to these scopes of relevance. 

CTP contexts do not presuppose or require locking mechanisms,
since  whenever user agents request an occasion to modify a
context, CTP  servers notify them whether the context has been
modified in whole or  in part since the time of the user agent's
local copy. CTP servers may  implement shared contexts as freely
interruptible or as "reservable"  according to diverse governing
principles. Separate protocols may  implement locking or other
"reservation" schemes on top of the CTP  layer, for contexts for
which that is desired. 

Message structure 

- requests, responses, occasions, events 

State distribution system 

- metadata, attributes, values, hosts 

Data structure 

- denormalized 

Errors / Responses 

Appendix A: CTP and RDF 

The correlates for RDF's subjects, predicates, and objects under
CTP  are uses, link types, and links. 

CTP/Use - [RdfSubject] 
CTP/Link Type - [RdfPredicate] 
CTP/Link - [RdfObject] 

CTP moves beyond RDF's knowledge-modeling assertions by
splitting  subjects into use types and uses, and then using the
combination of use  types with link types to define atomic
applications, contexts which  automatically provide all
fundamental information functions needed to  manage information
for any application. Because CTP is designed in this  manner, it
is perfectly suited for RDF applications. It simply goes  beyond
the knowledge-modeling purposes of RDF and the semantic web, to 
providing universal fundamental functions and implicit
interoperability  among all applications. 

Appendix B: CTP and REST 

Roy Fielding has articulated a comprehensive set of engineering 
principles which constitute an architectural style  called
"representational state transfer" (REST) intended to govern 
optimal Web architecture and Web application design. By
describing how  CTP's implementation of universal state transfer
compares with the  architectural principles of REST, we can
address its design  implications in an orderly and reasonably
complete manner. The chief  differences stem from the fact that
past architectural principles have  presupposed the arbitrary
complexity of state and data models, and  therefore have taken
certain design decisions geared toward managing  complexity,
which are unnecessary within CTP.


-- 

DRM is Theft!  We are the Stakeholders!

New Yorkers for Fair Use
http://www.nyfairuse.org

[CC] Counter-copyright: http://realmeasures.dyndns.org/cc

I reserve no rights restricting copying, modification or
distribution of this incidentally recorded communication. 
Original authorship should be attributed reasonably, but only so
far as such an expectation might hold for usual practice in
ordinary social discourse to which one holds no claim of
exclusive rights.





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS