Lists Home |
Date Index |
> 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;
> 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)
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. firstname.lastname@example.org