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] Postel's law, exceptions

[ Lists Home | Date Index | Thread Index ]

Bob Wyman wrote:

> It may work for Walter to claim that the data is his and not someone
> else's but it isn't ok for at pubsub.com . The function we're providing
> is content-based routing -- we're not doing re-publishing, data mining,
> or other stuff (yet). Thus, when we pass data to you, we're claiming
> that it *is* someone else's data -- it just got to you by flowing
> through our content-based PubSub routers. We don't claim the data and we
> take no responsibility for it (within the limits of applicable law...)
>         So, Perry's approach won't work for us... He's got a different
> kind of application. We are an intermediary: like proxies or traditional
> address-based routers.

Hi Bob.

We're intermediaries, too, and in fact have to be invisible or we blow it
for our users and won't get paid. We too are providing content-based
routing, probably of an even more exquisite form than you do:  if we
publish a document at a URL which we have reserved for the publication of
securities orders, we are inviting our users to rely on what they find
there to be a securities order, and to commit their own money and
reputation to executing and processing it as an order. What could be more
content-based routing than that?

Your question of whether we 'own' the data or it is 'ours' is the specific
legal issue at the heart of what we do. As a service provider, we act as
agent and we strive to be invisible to the true principal parties to the
transactions which our service facilitates. That is, we are not the
arbitrageur, nor a principal party in any other guise. We do, however,
make transactions between the true principal parties possible by
presenting the substance of each side of the transaction in a form
(well-formed XML!) which the principal parties can rely on to be
parseable, and in a location (a RESTful URL!) which the principal parties
rely on as an assertion of the nature of the document--order, comparison,
delivery instructions, etc.

Now please notice that identifying the content of a document by the URL at
which it is published says nothing of the form, nor of the content model,
nor of the data model, nor of any other schematic of that document. The
URL at which it is published asserts only that the document is, e.g., an
order, without offering a DTD or a schema or any other assertion of which
of the many forms of orders in common use this particular one might be. It
is most specifically not our business to involve ourselves in the form of
the document (beyond simple well-formedness, which is the sine qua non of
the entire exercise), because the form (meaning the content model or
schematic) in which a principal party emits a document means something
very specific about that document to that principal party--something which
we may well not understand, but in any case have no business messing with.
Likewise, we do not know what second principal party will take up the
other side of the transaction, and we certainly do not know the criteria
local to that principal party on which it decides to take up a particular
order, nor what of the content of that order is meaningful to that party,
nor how that party will instantiate for its own purposes what it finds in
a particular parseable document. We therefore have no business--and it is
counter to our business--to infer, let alone enforce, any content model or
schematic of a particular document. We have no way to know what content
model one party might intend or the other might expect, let alone what, if
anything, those models might have in common. In short, for what we do
validity, meaning conformance to a particular model, is not just beside
the point but is likely to be a pernicious interference with the
possibilities offered by the well-formed syntax itself.

Wendell has already quoted from Michael Sperberg-McQueen's keynote at
Extreme 2002. Let me also quote from a portion of that same speech, where
Michael graciously gave me credit, if humorously, for much more cosmic
principles than I claim:  "Perry's Processing State of Nature (in which it
is not the case that you are what you consume, but that you are what you
produce). That is just the point here. The party offering a transaction is
the party offering a transaction because it emits (i.e., produces) the
offer of that transaction. We facilitate by assuring that the document
making that offer is well-formed XML and by publishing that document at a
URL which asserts that the document is an offer. This is exactly the
converse of invoking a public interface or, its markup equivalent,
producing a document which validates to the warrants of an intended
audience. We don't know who the consumer of that document will be, nor for
what purpose it consumes the document, nor what it sees as the content
model of the document, nor what of the content of the document is of
interest to that consumer. In other words, the consumer's input
interface--its warrant--is opaque. That is why this is document-centric
processing:  the document, the output of each process, is published, but
the terms on which it could be consumed--not being a document, but an
abstraction--are not.

> What I'm getting at here is that it may be appropriate to speak of
> context when interpreting "Postel's Law." i.e. The closer
> your code is to a system boundary, the more important it is that you be
> "liberal" in being able to handle a very wide range of inputs
> potentially malformed inputs. At system interfaces, Postel's Law may be
> read as absolute. But, as you move away from an interface or boundary,
> your application semantics begin to take over and Postel's Law may be
> read as "Postel's Advice".

I believe that your notion that things are different at the border is
correct. Where we are dealing with XML documents, particularly as those
documents are published in the internetwork topology, the interface is
public on the output side but opaque on the input side. That is why the
question of of liberality in interpreting documents arises at all. If the
input side is a public interface, the satisfaction of that interface is a
binary choice:  there is no liberality allowed in interpreting whether an
input meets the warrants of the consuming interface. But where the
publisher of a document cannot know who will consume it or how, the
document is formed by the publisher's own understanding of it, without
regard to an expected consumer. Each consumer of that document may then
exercise a degree of liberality in deciding which of the many forms of,
say, securities orders, it is prepared to consume by first parsing each
document and then building on the different outputs of different parsings
the single private datastructure which for that consumer's own purposes is
the true form of an order.

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