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] Conf Call Minutes


Here are the minutes from todays call.  Enjoy.
 
Chris
 
1. URL Rewriting
    a.  Marker Syntax
 
It was suggested that in order for the most efficient parsing algorthithm the marker should use a sequence of characters (usually the longer the better).  The sequence should be made up of mostly uncommon characters  where as the sequences do not occurr frequently within the document. 
 
TO DO: Thomas will come up with some ideas for the begin and end markers and send them to the list.
 
    b.  URL Encoding/Decoding
It was discussed that we may require that all URL parameters that the entity generates should be UTF-8 encoded.  It was also dicussed that we may want to require that all of the markup generated from the entity be UTF-8 encoded.  There were some concerns that this was too limiting.  For most languages this is acceptable, however, there are exceptions. More information is needed. 
 
TO DO: Jane and Mike will start a thread with their concerns/suggestions.
 
2.  Window States (interfaces)
    a.  Can the producer determine which window state its in?
    b.  Can the producer determine the dimensions that it is available to operate in? (CC/PP)
 
Interfaces has not gone down this path yet.  We may need to allow a entity to present a link that will cause a window state change within the consumer.  Since this is not a critical feature, we will postpone this discussion until interfaces has defined this.
 
3.  Namespacing
 
There was some concern that there is too much complexity associated with requiring that the consumer rewrite namespacing for proxied resources.  Consumer URL rewriting should allow for static files, such as .js files, to include WSRP URLs.  Thus it seems likely that the consumer will need to rewrite these resources.  The main question is, should URL rewriting and namespacing be handled by the same mechansim or are there varioations in complexity which would require seperate mechanisms?
 
TO DO: we need to identify the variations in complexity between Consumer Namespacing and URL rewriting.
 
It was decided that for the preliminary spec we will pursue namespacing as it purtains to the rendered markup, and not concern ourselves with linked resources.  We will try to address this issue in the mean time.
 
4. Resource URLs
    a. Multiple Resource Locations
        - EXAMPLE: Portlet may have references to resources residing on different hosts.  Do we require that all resource URLs (wsia:resource) be fully qualified?  Other possibility is to allow the producer to provide a base URI.  This base URIL will be used by the consumer to identify the fully qualified location by appending the reosurce location to the base URI when the location is not fully qualified. 
 
Tabled for future call.
 
5.  Markup Spec - To be merged into main WSRP spec.
 
Provide prelimnary spec as it purtains to HTML/XHTML markup rules, URL rewriting, CSS styles, and Namespacing.  Should be accomplished by the middle of next week.
 
6. Attachments in getMarkup Responses.
    a. Use Case 
    b. SOAP vs. DIME
    c. Do we allow for attachments in the action or render request?
 
Tabled for future call.


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


Powered by eList eXpress LLC