RE: Proposed text for XMLBase

I'm still troubled by our approach to XML Base.  I will of course carry out 
my action item, but after some thought, I was thinking about how we would 
actually generate errors.

If we say that SOAP messages MUST not contain XML Base declarations, we are 
left with the way of finding when a SOAP message erroneously contains this. 

Let's follow through a scenario to illustrate.

1. Client sends SOAP message containing xml:base decls to SOAP processor
2. Processor receives SOAP message
3. Processor must validate SOAP message.  Now the rub begins.  In a simple 
Apache-ish implementation, I would pass the stream or parsed document to a 
stream or infoset Schema Validating parser.  In the current case of Apache, 
it doesn't know what XML Base is so my guess is that it ignores it.  Which 
isn't what I want.  I actually want the validator to return an error.  So I 
actually have to write some code to check whether xml:base exists, 
returning an error.  I probably lose my ability to use a streaming 
validator as I have to do a SOAP 1.2 validation step first to scan for 
xml:base declarations.

So my point is that we need a special step before an xml schema validator 
to check for xml:base decls to do the right thing. The other alternative is 
that the apache/msft parser/whoever else decide to add a flag to "return 
error if xml:base found", so they set another special parameter for our 
SOAP 1.2 case.

Conformance test suites will have fun with this.  Everybody that doesn't 
implement a "scan for xml:base and return an error" will be non-compliant. 
 If they implement the pre-parse step, we just slowed down every system by 
a perceptible amount.  Remember, the xml:base attribute could be way down 
the message, and the first intermediary (which might have implemented a 
streaming validator for only headers it was targeted) will have to find a 
report the xml:base error.  I guess we could say that each intermediary has 
to report an error if xml:base was found in headers targetted for it, but 
then we made our conformance way more complicated!  My validator would have 
to know about which bits to look for xml:base and which not...

If a vendor implements a "check xml:base during validating", surely it 
would be just as easy to just actually do the darned XML base 
implementation!

One other thing to think about is how we deal with future versions.  If 
SOAP 1.3 supports xml:base and SOAP 1.2 doesn't, I will surely need this 
flag and 2 different code sets in my parser.  if( attr = "xml:base") { if ( 
errorOnXMLBase) { throw xmlBaseException; } else { /* do the xml:base thing 
*/ }}.  Now my code jockey skills are pretty rusty, but it seems we 
definitely make each and every parser at least a tiny bit more complicated. 

The concern about snowballing of complexity is justified, but I sometimes 
think it's actually more complex to deal with these special cases than to 
try for architectural coherency, like being able to use relative URIs and 
standard tools!  I am extremely sympathetic to the concern about raising 
the bar too high or too quickly, but I'm concerned that we might put some 
wierd dent or zig-zag in the bar or even change the poles on the side to 
somehow avoid raising the bar.

FWIW, I'm hoping that one of the parser people or SOAP builders will say 
"no Dave, you've got it all wrong, it's no problem to phase this in.  We 
would do it xyz, so you see it's no problemo".

Cheers,
Dave


On Wednesday, September 05, 2001 1:55 PM, Champion, Mike 
[SMTP:Mike.Champion@SoftwareAG-USA.com] wrote:
>
>
> > -----Original Message-----
> > From: Noah_Mendelsohn@lotus.com [mailto:Noah_Mendelsohn@lotus.com]
> > Sent: Wednesday, August 29, 2001 6:02 PM
> > To: xml-dist-app@w3.org
> > Subject: Proposed text for XMLBase
> >
> >
> > On the telephone call this afternoon, I took a "to do" to
> > propose text for the use of XMLBase with SOAP.
>
> We discussed this more in today's call, and the resolution was to touch 
base
> with a number of interested parties and re-visit the issue later.  I'd 
like
> to express the opinion that we should adopt something like Noah's 
propoposed
> language however this process turns out.
>
> >
> > "This version of the SOAP specification does not support the
> > W3C XML Base Recommendation.  The xml:base attribute SHOULD NOT appear 
on
> the
> > SOAP-ENV:Envelope, SOAP-ENV:Body, SOAP-ENV:Header, or SOAP-ENV:Fault
> > elements;  processors receiving messages with such xml:base attributes
> > SHOULD generate a XXXXXX fault (details TBD).
>
> A number of objections were raised raised against this proposal (the 
factual
> basis for which will be clarified, but let's take them at face value for
> this discussion).
>
> 1) "SOAP is XML; anything supported in the XML InfoSet/syntax should be
> legal in SOAP"
>
> I'm very concerned that this approach leads inevitably to a snowballing
> complexity of XML related specifications.  If every spec has to support
> every other spec, we produce an indigestible hairball of a super-spec 
rather
> than a clean hierarchy of specs (and code modules implementing them) that
> build on what they need and only what they need.  Furthermore, SOAP is
> intended to be a universal wire format for communications between 
everything
> from mainframes to phones and perhaps even wristwatches.  It stands to
> reason that the bigger the spec, the harder it will be to implement
> effectively on very small devices.  If SOAP 1.2 raises the implementation
> bar too high, a de-facto quasi-standardized subset will become the "real"
> SOAP spec supported in the field, which means that the W3C Activity will
> have failed to do what it set out to do.
>
> 2) "The W3C Processing Models Workshop seemed to come to a consensus that
> XML+namespaces+xml:base should be the foundation of all future specs."
>
> As was pointed out on the conference call, this may or may not be true, 
but
> in any event there is no normative Recommendation in place that expresses
> this view.  If such a Recommendation is issued, then a future iteration 
of
> SOAP can support xml:base.
>
>
> 3) "SOAP should help promote the advancement of modern XML constructs 
such
> as xml:base"  (A paraphrase of what I understood Martin Gudgin to be 
saying
> on the call).
>
> I just don't think it is SOAP's job to advance XML; I think it's XML's 
job
> to provide an infrastructure for SOAP.  Interoperability is best ensured 
by
> staying away from the boundaries, not "pushing the envelope".
>
>
> OK, I realize that xml:base per se is pretty simple and probably won't 
push
> the envelope or create significant new problems for small devices, but 
I'm
> very concerned that we keep the larger considerations in mind as we 
debate
> the specific xml:base issue.
>
> Mike Champion

Received on Thursday, 6 September 2001 02:01:31 UTC