[wsrp] Errata requests for 5/8/2003

[Rich Thompson <richt2@us.ibm.com>]

Here is the current list of errata requests
we need to deal with:

#1. 4/24/03 (Atul Batra) 
If it's not too late, could you please include my name in Appendix D.2
of the specification titled "WSRP Committee Members"

Document: Spec 
Section: D.2 

New Text:  Atul Batra*, Sun Microsystems


#2. 4/24/03 (Rich Thompson) 
Version coming out of the public review period should be our 1.0

Document: Spec & wsdl 
Section: Property (shows in header and page 1). Also in wsdl and xsd file
comments. 

Old Text: 0.95 
New Text: 1.0


#3. 4/24/03 (Claus Von Riegen) 
Our WSDL uses qualified names to reference portType fault operations from
soap:fault elements. Taking the following WSDL fragment (that is part of
a wsdl:operation, which in turn is part of a wsdl:binding) as an example,
 <wsdl:fault name="AccessDenied"> 
   <soap:fault name="intf:AccessDenied" use="literal"/>
 </wsdl:fault> 
The "intf:" prefix makes the WSDL document invalid against the
WSDL 1.1 
schema, since the soap:fault name attribute is of type NCName. Removing
all occurrences of the "intf:" prefix should resolve the issue.

Document: wsrp_v1_bindings.wsdl
Section: throughout 
Old Text:  <soap:fault name="intf:...
New Text:   <soap:fault name="...


#4. 4/24/03 (William Cox) 
Section 1.2.3 -  Comment: The Consumer can also be viewed (and is,
indeed, so viewed by many) as a message switch, routing the results of
user interaction to the appropriate producer for action ( if the consumer
does not itself respond to the interaction).  We should consider mentioning
this in a future draft.

Document: Spec 
Section: 1.2.3 
Old Text:  and presents the aggregation
to the End-User. One typical Consumer is a portal,

New Text: and presents the aggregation
to the End-User. Because of this intermediary role, Consumers are often
compared to "message switches" that route messages between various
parties. One typical Consumer is a portal,


#5. 4/24/03 (William Cox) 
Section 1.2.3 - Comment: in ISO terminology, the consumer is a sort of
User Agent. 
 
Document: Spec 
Section: 1.2.3

I think this would be an addition to 1.2.3, but I wonder whether it is
strictly true. Doesn't a User Agent "process" the markup on behalf
of the End-User? Would adding this to the description be more confusing
than helpful?


#6. 4/24/03 (William Cox) 
Section 3.2 and elsewhere - "an IDL-like syntax" begs the question
of "which IDL?" -- this is an editing nit, but got annoying after
the third or fourth time.

Document: Spec 
Section: 3.2+
Old Text: IDL-like syntax 
New Text: IDL style syntax


#7. 4/24/03 (William Cox) 
Section 3.1.2: Why is WS-I.org listed as an "emerging standard"?
Given that the Basic Profile is out (which is one more spec than WSRP has
out so far  :-) ), we should list the basic profile in the Existing
Standards list. It's OK to also list ws-i.org in the "emerging standards"
list with (say) security profile mentioned. 

Document: Spec 
Section: 3.1.2
Old Text: WS-I.org
- Defines profiles for use of web services standards such that interoperability
is maximized.
New Text: WS-I.org
- Defining additional profiles (e.g. Security) for use of web services
standards such that interoperability is maximized.

Document: Spec 
Section: 3.1.1
New Text: WS-I.org
- Has defined a base profile for use of the WSDL, SOAP and UDDI web services
standards such that interoperability is maximized.


#8. 4/24/03 (William Cox) 
Section 3.1.2: "JSR168 – Java Community Process for standardizing
a portlet API." should be written "JSR 168 - a Java Community
Process effort for standardizing the Java Portlet Specification"

Document: Spec 
Section: 3.1.2 
Old Text: JSR168 - Java Community Process
for standardizing a portlet API.
New Text: JSR 168 - Java Community Process
effort defining the Java Portlet Specification.



#9. 4/24/03 (William Cox) 
Section 5.1.4: "We STRONGLY RECOMMEND these characters be chosen from
the first 127 characters of the Unicode character set, so that the length
is no longer than 4096 characters regardless of whether it is represented
in Unicode, ASCII or a byte[]." 

This sentence has several problems.  (1) the length of a 4096 character
string, wchar or not, is always 4096 characters. What you mean is 'length
is no longer than 4096 bytes.'  (2) byte[] should be written 'byte
array'.  So, rewritten, it should read 

"We STRONGLY RECOMMEND these characters be chosen from the first 127
characters of the Unicode character set, so that the space consumed is
no greater than 4096 bytes regardless of whether it is represented in Unicode,
ASCII or a byte array." 

Document: Spec 
Section: 5.1.4
Old Text: We STRONGLY RECOMMEND these
characters be chosen from the first 127 characters of the Unicode character
set, so that the length is no longer than 4096 characters regardless of
whether it is represented in Unicode, ASCII or a byte[].

New Text: We STRONGLY RECOMMEND these
characters be chosen from the first 127 characters of the Unicode character
set, so that no more than 4096 bytes of storage is required regardless
of whether it is represented in Unicode, ASCII or a byte array.


#10. 4/24/03 (William Cox) 
Section 14: The definitions look pretty much OK.  The word hyperlink
didn't work (404) for the second two. 

Document: Spec 
Section: 14

Action: Fix target for the second two hyperlinks to match the displayed
text.


#11. 4/24/03 (William Cox) 
XML Spy complained  that the first definition was invalid: "Localized
String -- Invalid - no attribute with name xml:lang has been defined in
this or in included/imported schemas.  (As part of another schema,
it might still be OK)" 

Document: WSDL 

[RT] I'm not sure that this isn't a bug in XML Spy. We do import the schema
that defines xml:lang. It may be trying to dereference this through a definition
of the "xml" prefix to the actual namespace (http://www.w3.org/XML/1998/namespace),
but this is explicitly a prefix association that XML defines and declares
as not available for redefinition by the xmlns: method of associating prefixes
with namespaces.


#12. 4/24/03 (Andrew
Wright <andrew.wright@oracle.com>)
I just noticed in 0.95 of the WSRP spec pg 64, ln 20, an URL rewriting
example is given as: 

wsrp-rewrite?wsrp-urlType=blockingAction&wsrp-secureURL=true&wsrp-navigationalState=a8h4K5JD9&interactionState=fg4h923mdk/wsrp-rewrite

I think it should be: 
wsrp-rewrite?wsrp-urlType=blockingAction&wsrp-secureURL=true&wsrp-navigationalState=a8h4K5JD9&wsrp-interactionState=fg4h923mdk/wsrp-rewrite

Document: Spec 
Section: 10.2.1.8 (example 3) 
Old Text: wsrp-rewrite?wsrp-urlType=blockingAction&wsrp-secureURL=true&wsrp-navigationalState=a8h4K5JD9&interactionState=fg4h923mdk/wsrp-rewrite

New Text: wsrp-rewrite?wsrp-urlType=blockingAction&wsrp-secureURL=true&wsrp-navigationalState=a8h4K5JD9&wsrp-interactionState=fg4h923mdk/wsrp-rewrite


#13. 4/30/03 (Yossi Tamari) 
Change definition of the Extension type: 

Document: Spec 
Section: 5.1.1 
Old Text: [O] Object                
any[] 
New Text: [O] Object                
any 

Reason: The definition here is of a single Extension field, not of the
array. Anywhere else in the spec we use an array of Extension ([O] Extension
extensions[]). This also matches our wsrp_v1_types.xsd better.


#14. 4/30/03 (Rich Thompson)
Change definition of the any field for the Extension type. Several developers
from various companies have emailed me about the requirement that the extensions
come from a non-WSRP namespace. The question centers on how to then reuse
the types defined within the WSRP namespace. I suggest adding the following
sentence: 

Document: Spec 
Section: 5.1.1 

New Text: While the element definitions for these extensions
are required to be in a namespace other than WSRP, the reuse of the types
defined within the WSRP namespace by those definitions is encouraged as
this increases the likelihood of the receiving partner being able to deserialize
the extension in a useful manner. 


#15. 5/5/03 (Rich Thompson) 
This conformance statement refers to the registrationPropertiesDescription
field as required, but the IDL and WSDL both say it is optional.

Document: Spec 
Section:  5.2
Old Text: The minimum information
a Producer MUST return from getServiceDescription() is that which
declares what is required for a Consumer to register (i.e. the requiresRegistration
flag and the registrationPropertyDescription
field) with the Producer [R300][R301][R303].

New Text: The minimum information
a Producer MUST return from getServiceDescription() is that which
declares what is required for a Consumer to register with the Producer
(i.e. the requiresRegistration
flag and whenever additional data is required, the optional registrationPropertyDescription
field) [R300][R301][R303].


Rich Thompson