|
Chris,
Sorry to jump in without being a formal part of the sub-committee, I am
sure I am missing lots of discussion and useful info.
I have one comment regarding the distributed URL writing
algorithm.
Whereas I am not involved enough on the work in the markup subcommittee
to have a preference for the mechanisms used, my strong point throughout
different such discussions within both WSRP and WSIA is that as an industry
standard (versus a specific portal implementation), we should make sure we
support non-trivial scenarios which people use in practice, and in
particular those that include JavaScript.
For example, roll-over code often creates image URLs programmatically,
e.g.,
img.src = baseUrl + "/i/img" + imgNum +
"_up.gif";
etc.
The same goes with menu bar URLs, e.g.,
document.write("<a href='" + baseUrl + "?target=" +
menus[i].submenus[j] + '>");
I am not sure whether you have considered them (on the surface, it wasn't
clear to me how the $$$WSIA-URL-PREFIX$$$ solves those issues, which is why I
wasn't sure). I am not sure whether these scenarios have to be addressed in the
main flow of the protocol, but I believe it should be possible for a company
creating portlets to support them (e.g., if MapQuest or SalesForce.com want to
create a smart portlet with dynamic behavior, there should be a way to make it
happen, even if it requires some additional - or even non-trivial - work).
I believe that the joint WSIA/WSRP
subcommittee (headed by Alan) has done some initial work around trying to tackle
those issues, although I am not familiar with the latest work that they have
done.
Cheers,
Eilon
Markup members,
Here is the agenda for next weeks conference
call. The conference call dial in info
will follow, but it's the same as usual.
Agenda:
1. URL Rewriting
2. Visual Themes CSS Classes
continued
3. Markup Fragment Rules
Items to be covered (to help guide the
conversation)
1. URL Rewriting
1.1 Mechanism used to demarcate URLs
1.1.1 The
producer uses an escape sequence that contains all the parts of the URLs
followed optionally by some parameters. The aggregator then searches this
sequence and reconstructs the URL using the correct URL
prefix.
Advantages: this
method is parsing efficient and should be easy to implement. This
algorithm applies to both aggregator and producer. Have we come to
a consensus that his is the basic mechanism of which URL rewriting will
occur?
1.1.2 What pieces of a URL need to be replaced? Is
there a difference between action URLs and resource URLs?
1.1.3 How are resources referred too? Do all
consumers implement a resource server which handles proxying of
resources? Such that http://consumer/portlet-resources/portlet-proxy-name, where for each portlet that is registered with the
consumer proxying will be handled for that portlet at a certain
consumer server path. May be getting implementation specific.
1.1.4 Does the producer indicate
if a resource should be proxied and if it should be cached? Might
be off topic.
1.1.5 What will the prefixes
be? Can't be a tag as elements can not belong inside of
attributes. Should be a valid xml string. Maybe $WSIA-URL-PREFIX$,
or something to that affect.
2. CSS Classes
2.1 Table - Do we need a custom class to describe wsia-table for
backgrounds, fonts, etc?
2.2 Sections - Define "trail"
2.3 Forms - There are some issues with radio
buttons and checkboxes. If you change the background-color of the
wsia-form-field the checkboxes and radio buttons look awkward when comparing
NS to IE.
2.4 Menus - Are there other areas of a menu
that need to be represented by styles?
3. Markup Fragment Rules
3.1 Define a list of tags
that will discourage or disallowed in the containing pages head
tag. For example: <title> might
be disallowed.
3.2 We need more specifics as to how the
producer generates and passes back head markup as well as if and how we make
this extensible so that
additional markup tags can be support beyond the head
tag.
|