Cart
[Home] [By Thread] [By Date] [Recent Entries]
> FWIW, this was the original intent of the SOAPAction header from earlier > versions of SOAP. It still is, though we're attempting to relocate it to the "action" header on the SOAP media type; http://www.markbaker.ca/2001/12/draft-baker-soap-media-reg > Along those lines, I think I would rather know the local name and > namespace name of the root element than every stinking namespace > declaration that is in use. More often than not, the root element > implies the remainder of the document. It implies the first processor, which more often than not is all you need, for sure. I think bringing out the namespaces is a useful optimization for enabling ahead-of-time construction of a compound processor. But it's really an optimization for a mechanism that doesn't yet exist; standardized dispatch keyed off namespaces. I'm working on that right now, but it's a little more complicated than I thought it would be. Re Simon's draft, I have a comment about this sentence; "While a list of namespaces cannot tell a recipient application everything about the use of those namespaces and there interactions in a given document, it can provide a baseline understanding." I don't think it helps with the "understanding" at all, by itself. You need the document's structure to provide the context necessary for extracting meaning. Without that context, "all" I think you get is some idea of what processors you'll need to process that document. That's an important optimization, but it's not "understanding". Ideally, this optimization would work together with the rules provided by the aforementioned namespace dispatch mechanism. I'm working on that right now, and it's to a point where I have the basics pencilled in, but some of the detail is eluding me (most wrt schemas). You can watch my work in progress (this is the version I'm actually editing on-the-fly) here; http://www.markbaker.ca/2002/01/draft-baker-generic-xmlns-dispatch Comments welcome. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@p... http://www.markbaker.ca http://www.planetfred.com
|
