[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: The subsetting has begun


internetwork processors
"Cavnar-Johnson, John" wrote:

> How would standardizing a class of processors that don't process the
> internal subset, entities, etc. jeopardize what you have achieved? If
> there are costs to my proposal that I don't see now, I would like to hear
> them, but don't impute to me positions that I do not hold. Your
> processor(s) can still handle the documents that these systems would
> produce. If you use the features that are eliminated from the subset, then
> consumers of your documents would need to use a processor capable
> of dealing with them.  Is that cost really significant, and if so, please
> explain?

As last week's discussion made clear, such processors are non-conformant to
the XML Rec. That is the reason de jure not to create documents intended for
such processors and then call either those documents or those processors
'XML'. But you are correct that here I am arguing against a different
danger. As a processor of documents I am not a party to bilateral or even
cartel agreements as to the form of those documents. The unique advantage of
well-formed XML documents in the internetwork topology is that I do not have
to be. The salient point of processing nodes in the internetwork topology is
that they are uniquely identified by what they produce and publish (as
documents), but not by what they consume. This is in direct contrast to
objects identifiable by the interfaces on which they are invoked--that is,
what they are obligated to consume and process if it is presented in the
expected form.

In the processing I do I am often the 'man in the middle', which is an
unacceptable security risk in processing invoked by satisfying the expected
interface, but in the internetwork topology is not only benign but is the
underlying mechanism for much useful work. Instead of money managers
formatting their orders--and indeed determining the substance of those
orders--on the basis of what a particular broker or party executing those
orders expects, they may in the internetwork topology compose those orders
precisely as they themselves understand them and then publish them at an
appropriate URI for retrieval by an appropriate party under http-based
security mechanisms. Though the creator of an order may know of only one
interested party downstream, there are in fact many who have a part in the
various operations of fiduciary settlement/reporting/accounting. Rather than
the creator of the order having to know of all the places where physical
paper would have to go for processing in a manual system--and having to
format an electronic document specifically intended for the different
requirements of each of those processors--in the internetwork topology a
known downstream party can delegate its authority (as effectively it does in
non-automated processing) to various specialized processors. I am not only
such a processor, but intervene at a number of places in the pipeline, all
without most of the parties interested in a transaction even knowing of my
existence. For each such process, I am not an 'intended' recipient. Out of
what is published I choose what data I need on the basis of what I uniquely
know to be my specific requirements for processing--and those requirements
are not only opaque but are often trade secrets--but I publish my output as
well-formed XML which can be used by interested parties in ways which I
never expected or intended.

Now as you say:

> If you use the features that are eliminated from the subset, then
> consumers of your documents would need to use a processor capable of
> dealing with them.  Is that cost really significant, and if so, please
> explain?

I imagine you now see that I must expect that consumers of my documents are
using a processor conformant to the XML Rec. Sure, there are plenty of cases
where what I produce and publish could be handled by some subset parser, but
worrying about what those cases are, or worrying at all about how any one
consumer of documents has to be treated differently from every other
potential consumer of those same documents, obviates the essential advantage
of the well-formed-XML-plus-internetwork-topology paradigm. There is also a
risk on the other side, which I alluded to in the earlier post. Wherever the
form in which documents are created is conditioned by agreements between a
creator and its expected consumers, the risk is that they will agree on
out-of-band semantics which allow them to reduce the content of the document
itself. On the basis of such agreements the 'expected' creators and
consumers become a cartel from which I am excluded, and their documents
become impoverished of information with which I might otherwise perform
useful processing. That cost is not only significant, but potentially fatal
not only to what I can do today but to the larger promise of XML.

Respectfully,

Walter Perry


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.