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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Roles and functions [was: many-to-many]

[ Lists Home | Date Index | Thread Index ]

Like Tim Bray, after I read enough of this I wonder whether I am missing some
circuit in my brain, though I am untroubled by somewhat different concerns than
is Tim, viz.:

I embraced the internetwork architecture because the roles and functions of the
constituent nodes were limited and explicit, and the URL scheme curtailed the
scope of assumptions or axioms which would otherwise be incompatible with my own
processing requirements. In the internetwork architecture servers return entity
bodies--bits on the wire--which inevitably carry formatting or presentation
bespeaking the assumptions or intent of those who design and manage the content
of a server. The URL scheme, in making explicit that those bits pass from one
domain into another, also makes clear why I don't have to care about those
assumptions, nor respect the presentational manifestation which they assume:  the
scope of the server's intent is limited, if not more severely, then at the least
to the boundary of its domain name. There are means other than http by which an
equivalent entity body might be conveyed--not just to me but to a host of
recipients, interested for their own idiosyncratic reasons:  email, instant
messaging, diskettes delivered by sneakernet all deliver bits processable by
software into a domain--and into a domain of assumptions and
expectations--differing from the domain where the content was created. The
internetwork architecture must assure that the bits survive the journey intact,
but it also indicates why the assumptions should not:  they manifestly belong to
a different domain, in a domain naming scheme particularly suited to making the
boundaries of local assumption and the scope of local intent.

To process whatever of use might be available in the bits I receive, I must first
instantiate a data structure particularly suited to my own processing. It would
be as foolish for me to assume that the bits I receive are noticeably related to
the form in which I must instantiate data for my own use as it would be for the
creator and publisher of those bits to assume that I should follow the, to me,
accidental form of their format or presentation in my independent instantiation
of my own data. The great service which the creator and publisher have done me is
in publishing data. They may limit access to that data to only the smallest
audience of those who can demonstrate appropriate authorization, but they have
still published the data. 'Publish' here means that they have made the data
available without reference (or much thought) to the form in which I might
require it. The content published is an expression of its creator's expertise,
including in the form of its presentation an inevitable manifestation of the
creator's point of view. It is not private-use material specifically intended for
my particular instantiation and subsequent use of it. The domain name at which
such data is published stamps the published form of data (and every retrieval of
it, which must address that name) with the scope and boundary of the assumptions,
the axioms and the intent  which that data might reasonably convey. It is,
ironically perhaps, by imposing these explicit boundaries on every inter-node
transaction that the internetwork achieves universal scale. There is no center to
limit the foederal scalability of the internetwork, not even the center of an
original form of content, from which every use and re-use might be imagined as on
ripples radiating outward.

It is the task of a sufficiently capable server to negotiate content and return a
well-chosen representation--a particular entity body of bits on the wire. The
server offers a selection of various presentations of particular data, but from
that we must not infer some platonic form of which those choices are the instance
manifestations. It is an accident of labelling within the URL scheme that those
forms appear to have some underlying identity--or, perhaps better, it is an
assertion from that server through URL labelling that there is some commonality
in those manifestations. That does not establish any meaningful identity or even
similarity of data, outside of URL labelling, even at the server, let alone any
commonality which should be respected by a client explicitly in a different URL
domain and with different understanding of and uses for that data.

Functionally, the relationship of URIs to things--at least those things which are
comprehended by software, which is to say processable data structures--is
necessarily many-to-many. This is a chief feature of the URL naming scheme.
Through URL labelling many manifestations of data may be marked with the same
name and the functional question left to the server of which entity body to
return in response to a particular request. Once safely transported to the node
which acted as client in that request, the entity body transmitted is not the
entity body required; it is only an ephemeral intermediate form preceding the
data structure which that node actually requires and must instantiate before
doing any useful processing. Where 'things' are the things that software
comprehends, the nature of processing those things by addressing them through
URLs necessarily places them in a many-to-many relationship. The only way to
unify the many physical manifestations which might be labelled with a given URL
is to assert that out of that identity of naming we create some actual identity
or some platonic form of which all the physical instances are manifestations. But
at the functional level of the working internetwork topology, many data
structures share an accidental identity of naming in a URL at which they are
addressed for retrieval on the way to instantiation in varying forms.

Respectfully,

Walter Perry






 

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

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