OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp-markup message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: [wsrp-markup] [wsrp][markup] August 21 Conf Call Minutes

Better late than never :)

Minutes From August 21 Markup Conference Call

1. URL Encoding
    a. Revisit -  Current thought is that URLs are to be encoded using UTF-8.  The URL is then to be properly escaped using %HH notation.  Since there are variations in the way browsers encode characters (based on page encoding and the "accept-charset" header) we may need to rethink our requirements.

- Markup Response needs to carry the char set information that the response is generated in.  This is currently not in the spec and appears to be an oversite.

- A WSRP producer should encode URLs in the same char set  encoding used in the markup response.  

- Producer written URLs must be in the proper form, the producer has the extra burden of encoding in the Consumers character set. Consumer URLs are rewritten by the consumer and thus character set conversion can take place as well as the escaping.

- WSRP should provide a strong recommendation that UTF-8 should be the charset of choice for consumers and that producers adhere to this charset.  

2. Attachments
    a. Prototype using optional DIME tags within a non-DIME consumer (status from Carsten).  

 - DIME specific attributes can be placed in the WSDL interface and the proxy code generated by AXIS will only need slight modifications.

TODO: How do other JAX-RPC implementations handle this?

    b. More specifics on the consumer's relationship with attachment binding:  
            Dynamically created proxies and Pre-created proxies.  (Andre and Carsten)

 -  A producer must offer one base binding per factor.  The producer may also offer a soap-attachment binding or a DIME attachment binding, again this is per factor if multiple factors are available.

- We had a very long/interesting discussion on the issues related to pre generated proxies that pertain to multiple binding types across factors.  This discussion will move over to the interfaces committee to establish the approach in which binding information is described to the consumer and how multiple factors can be implemented with pre compiled proxies.

    c.JAX-RPC status for possible support for DIME.    

 - JAX-RPC have intentions of supporting DIME in  the next release.  March-April time frame.  This is not official.

3. Resource Rewriting
    a.  Can non-markup resources be retrieved directly from the getMarkup call to the entity. (Dependencies on Attachments)

Wait for JSR 168 resolution.  This should be resolved at the JSR 168 F2F In late August.

    b.  Does JSR 168 allow resource retrieval directly from the portlet?

See (a)

    c.  If we require (a), Is the consumer required to rewrite resources other than those served by getMarkup?

This has yet to be determined.  We will bring this up at the September WSRP F2F.

4. Button and Label consistency across portlets 
        a. How can configuration interfaces maintain a consistent look and verbiage across entities.  For example when saving customize information should buttons read "apply" or "save".  
        b.  Consumer Offered Resources - See current rev of the spec.

-  The consumer offered resources ( in the spec) was added to address the issue of maintaining a consistent UI across portlets so that certain verbiage and images are consistent across portlets.  
- In the case where producers are rewriting the consumer may still have to rewrite and consumer offered resources that were referred to.  

TODO - Revisit, Carsten will look at the possibility of allowing text as well as resource references with this model.  Bring this up at the F2F as well.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC