Re: [soapbuilders] Publication of the first W3C Working Drafts of SOAP Version 1.2 and of the XML Protocol Abstract Model

Hi, Martin!

Thank you for your comments.

> > 4. No clarification about "top level of serialization" (did I
> miss
> > it?)
> What kind of clarification were you looking for?
There is no definition of "top level of serialization" and maybe it's
a common term, but I couldn't find it and spec doesn't have any
examples on multiref serialization. There should be at least one
(better two, one of them should show multirefs shared between Header
and Body).

> OK, I think this is an area that needs some clean up. I think it
> should work like this;
> 
> 1.    enc:offset appears on the array element only.
> 2.    enc:position appears on the array members only.
> 
> I don't think offset makes sense on array members.
I agree, I was confused by [5.1.8]: 'A SOAP array member MAY contain
a "enc:offset"'. Probably wording should be changed to support your
clarification.

> I don't think position makes sense on the array itself unless that
> array is in fact a member of an outer array.
> 
> Open question, is position absolute or relative to offset? I prefer
> the former.
That's not the only question.
- Should ALL element be marked with position attribute if one of them
is marked?
- What is the position of element that is NOT marked with position
attribute, but previous one is marked (if we allow not all elements
to be marked). Is it previous+1? something else?
- What should be the ORDER of elements with position attributes? any?
ascending?
- If position is absolute, what about elements that are NOT marked
with position, but Array element has offset attribute?
<Array enc:offset="[2]">
  <item enc:position="[1]"/>
  <item />
</Array>

My proposal is simple. enc:offset and enc:position attributes should
NOT be mixed on the same array (if mixed, position should be
relative, thus offset should be applied AFTER position). enc:position
attribute should be specified on ALL elements of the array (order is
not significant, but there should not be duplicates).

I think also should be clarified that arrayType specifies the SIZE of
resulting array, and not the number of elements, so 

<Array enc:arrayType="xsd:anyType[10]">
  <item />
  <item />
</Array>

is legal, but 

<Array enc:arrayType="xsd:anyType[10]" enc:offset="[10]">
  <item />
  <item />
</Array>

is not.

Spec also doesn't say that offset and position can't be negative (it
just says that arrays are 0-based). Should be clarified imho.

One more thing. Spec itself has transition mechanism that work for
1.1 and 1.2 and eventually will describe transitions between any
versions. At the same time, description provided for HTTP Extension
Framework [6.3] doesn't let you use that transition mechanism with
M-POST requests. If you want to support both 1.1 and 1.2 you need to
accept requests for both, but definition for M-POST allows you to
accept only 1.2 since extension identifier is fixed for 1.2 version. 

In general I think it's a mistake to use DIFFERENT extension
identifiers for different versions. It should be unique enough, but
it shouldn't care any information about SOAP version (imho) otherwise
we will need to duplicate transition logic on transport level that
has nothing to do with SOAP content.

Probably we need to keep the same identifier that was used for 1.1 or
clearly specify transition logic (if any) used for M-POSTs.

Best wishes, Paul.

--- Martin Gudgin <marting@DEVELOP.COM> wrote:
> 
> ----- Original Message -----
> From: "Paul Kulchenko" <paulclinger@yahoo.com>
> To: <soapbuilders@yahoogroups.com>; <soap@discuss.develop.com>
> Cc: "Hugo Haas" <hugo@w3.org>
> Sent: Tuesday, July 10, 2001 1:31 AM
> Subject: Re: [soapbuilders] Publication of the first W3C Working
> Drafts of
> SOAP Version 1.2 and of the XML Protocol Abstract Model
> 
> 
> > Hi, All!
> >
> > New spec draft needs new issue list, right? :))
> > Here is the list of what I can see after the first reading (i'm
> not
> > subscribed to xmlp-comments@w3.org, can someone forward message
> there
> > if it's correct).
> >
> > 1. mustUnderstand is fixed to allow '1/0/true/false' (boolean in
> > schema), but specification explicitly says only about '1' and '0'
> 
> Thanks. I've put this on the editors 'todo' list
> 
> >
> > 2. Example 7 specifies faultcode as Name instead of QName
> 
> Yes, should be env:MustUnderstand, sorry. On the editors 'todo'
> list.
> 
> >
> > 3. Spec uses xsi:null="1" where xsi:nil="true" should be used
> (5.1.9
> > is one example). And it's only "true", not boolean "true/1".
> 
> On the editors 'todo' list.
> 
> >
> > 4. No clarification about "top level of serialization" (did I
> miss
> > it?)
> 
> What kind of clarification were you looking for?
> 
> >
> > 5. 5.1.8 says: 'A SOAP array member MAY contain a "enc:offset"'
> and
> > use enc:offset and enc:position in the same context, whereas
> refers
> > to [5.4.2.1 Partially Transmitted Arrays] which says about
> enc:offset
> > on Array element itself. Schema shows enc:offset on Array element
> > also.
> 
> OK, I think this is an area that needs some clean up. I think it
> should work
> like this;
> 
> 1.    enc:offset appears on the array element only.
> 2.    enc:position appears on the array members only.
> 
> I don't think offset makes sense on array members.
> I don't think position makes sense on the array itself unless that
> array is
> in fact a member of an outer array.
> 
> Open question, is position absolute or relative to offset? I prefer
> the
> former.
> 
> >
> > 6. Schema defines root attribute as boolean, whereas spec says
> only
> > about "0/1" as values.
> 
> Thanks. on the editors 'todo' list
> 
> >
> > 7. Appendix C says: 'The upgrade extension contains an ordered
> list
> > of namespace identifiers of SOAP envelopes that the SOAP node
> > supports in the order most to least preferred.', but doesn't give
> any
> > examples on how to do it for more than one envelope supported and
> I
> > can't figure it out from the text.
> 
> Thanks. Hopefully we will add an example in the next WD.
> 
> >
> > 8. D.2 Schema changes doesn't reflect changes from ut-type to
> anyType
> > (anySimpleType).
> 
> The ur-type didn't change. All that happened was the
> schema-for-schemas now
> has a definition of the ur-type called 'anyType'. That said I
> should have
> noted in the table that the element decl and complex type named
> 'ur-type'
> had been replaced with an element decl called 'anyType'. On the
> editors todo
> list.
> 
> >
> > Best wishes, Paul.
> >
> 
> Thanks very much for the feedback
> 
> Martin Gudgin
> DevelopMentor
> 
> 
> 
> 
> 
> -----------------------------------------------------------------
> This group is a forum for builders of SOAP implementations to
> discuss implementation and interoperability issues.  Please stay
> on-topic.
> 
> To unsubscribe from this group, send an email to:
> soapbuilders-unsubscribe@yahoogroups.com
> 
>  
> 
> Your use of Yahoo! Groups is subject to
> http://docs.yahoo.com/info/terms/ 
> 
> 


__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail
http://personal.mail.yahoo.com/

Received on Wednesday, 11 July 2001 06:25:35 UTC