Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Postel's law, exceptions
 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
