wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] [CR310] - Add doctype fields
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Wed, 23 Mar 2005 09:49:48 -0500
Why wouldn't the portlets who need it
ask for a doctype parameter? I expect this is a minority of portlets and
so wouldn't expect Consumers to supply it as a normal course of affairs.
Rich
Subbu Allamaraju <subbu@bea.com>
03/23/05 09:39 AM
|
To
| wsrp@lists.oasis-open.org
|
cc
|
|
Subject
| Re: [wsrp] [CR310] - Add
doctype fields |
|
With doctype and cc/pp, the Consumer is supplying
some data that the
portlet could make use of for rendering, and it is not necessarily
anything that the portlet asked for. So, I'm not sure if public
parameters is a good fit.
We could possibly have an extensible set of parameters, and the spec
could list (non-normative) some common parameter names and what they mean.
Subbu
Rich Thompson wrote:
>
> The public parameter concept doesn't fit well with a bidirectional
flow
> of data. However, I would agree that the proposal for doctype does
fit
> well with the public parameter model (Portlet requests Consumer supply
a
> particular piece of data and has reasonable fallbacks should the
> Consumer choose to not supply it).
>
> Subbu, would the spec defining such a public parameter for Portlet
reuse
> satisfy your use case?
>
> Rich
>
>
> *"Andre Kramer" <andre.kramer@eu.citrix.com>*
>
> 03/23/05 09:06 AM
>
>
> To
> "Subbu
Allamaraju" <subbu@bea.com>, <wsrp@lists.oasis-open.org>
> cc
>
> Subject
> RE:
[wsrp] [CR310] - Add doctype fields
>
>
>
>
>
>
>
>
> What prevented us leveraging the new public parameters feature for
CC/PP
> was its inability to return a value. Maybe that should be addressed
so
> that extensions could use the (render) parameter extension mechanism?
>
> Regards,
> Andre
>
> -----Original Message-----
> From: Subbu Allamaraju [mailto:subbu@bea.com]
> Sent: 23 March 2005 14:00
> To: wsrp@lists.oasis-open.org
> Subject: Re: [wsrp] [CR310] - Add doctype fields
>
> I agree with you both on the concern about proliferation of these
> parameters. Any thoughts on how such well-known extensions should
look
> like?
>
> Subbu
>
> Michael Freedman wrote:
> > Additional good questions that add to my reservation of
adding this to
>
> > MarkupParams. I think I would rather us begin to
define well-known
> > extensions for consumers/producers to take advantage of
if/when
> > necessary. Otherwise I worry the parameter list will
continue to grow
>
> > over time as we find new use cases for additional information.
[By
> the
> > way, this was also at the root of my questions/concerns
about adding
> CC/PP]
> > -Mike-
> >
> > Rich Thompson wrote:
> >
> >>
> >> Interesting point, but one could easily argue this
is an issue with
> >> what the framework makes available to the component
rather than a
> >> general issue (i.e. that decision could be easily changed).
> >>
> >> Thinking about this further led to the following questions:
> >>
> >> 1. Isn't this an html specific issue (i.e.
doctype in addition to
> >> mimetype)? If so, that reduces
its fundamental value to me.
> >> 2. Wasn't the introduction of several
doctypes part of a
> >> recognition on the part of the
html standardization group that
> a
> >> significant body of legacy web
sites existed? Should this be
> >> carried forward into the WSRP-enabled
portlet world,
> >> particularly in light of this
quote from our Primer; "WSRP
> >> raises the bar of conformance
for this standard in many
> respects
> >> for what constitutes a good or
effective portlet
> implementation.
> >> The specification makes specific
recommendations regarding
> >> markup fragment rules, representing
state, ensuring security,
> >> etc., with an eye toward maximizing
the usefulness and
> integrity
> >> of portlet services."? If
WSRP is truly raising the bar, it
> >> seems advocating adherence to
the strict doctype should be part
> >> of that.
> >> 3. Are there any problems if a portlet
generates a fragment of
> >> "strict" html which
gets included on a page with the
> >> transitional html doctype?
> >>
> >>
> >> Rich
> >>
> >>
> >> *Michael Freedman <Michael.Freedman@oracle.com>*
> >>
> >> 03/17/05 06:13 PM
> >>
> >>
> >> To
> >>
wsrp@lists.oasis-open.org
> >> cc
> >>
> >> Subject
> >>
Re: [wsrp] [CR310] - Add doctype fields
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> I think the answer to whether the "consumer"
knows the doctype is a
> >> qualified "no". Take for example someone
who wants to build portlet
> >> support into a generic application development platform.
The
> platform
> >> would expose a developer friendly API for using/manipulating
> >> consumer-side use of portlets and hide the gory details
of
> >> communicating with [remotw wsrp] portlets. In
such an environment
> >> there is a clean and distinct separation between application
code
> that
> >> describes the structural rendering of the a consumer
response and any
>
> >> given component in that structure that provides a portion
of the
> >> rendition. Because doctype is likely just markup
expressed in the
> >> page, such components may find it difficult if not
impossible to
> >> determine what it is. I.e. whereas you can get
the locale, mimetype
> >> and characters set from a servlet response you can't
get the doctype.
> >> -Mike-
> >>
> >> Rich Thompson wrote:
> >>
> >> This change request raises a couple of questions for
me:
> >> 1. Will the Consumer always "know" the doctype
for what will be
> >> returned to the user agent at the time it invokes getMarkup?
I think
> >> the answer is "yes", but we should review
this carefully.
> >> 2. Are there other characteristics of the aggregated
page that the
> >> Portlet could make good use of? Currently we have locale,
mime type
> >> and character set ... any others?
> >>
> >> Rich
> >>
> >> *Subbu Allamaraju **_<subbu@bea.com>_* <mailto:subbu@bea.com>
> >>
> >> 02/02/2005 11:19 AM
> >>
> >>
> >> To
> >>
_wsrp@lists.oasis-open.org_
> <mailto:wsrp@lists.oasis-open.org>
> >> cc
> >>
> >> Subject
> >>
Re: [wsrp] [CR310] - Add doctype fields
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> For the reasoning, I meant to say
> >>
> >> "Due to the legacy nature of web, some portal
sites are designed to
> >> generate either _strict_ or quirks mode HTML ..."
> >>
> >> I missed "strict" in my request sent to Rich.
> >>
> >> Subbu
> >>
> >> Rich Thompson wrote:
> >> >
> >> > Document: Specification
> >> > Requested by: Subbu Allamaraju
> >> > Section: 6.1.9 MarkupParams Type
> >> > Page: 31
> >> > Old Text:
> >> > New Text:
> >> >
> >> > [O] string
doctype
> >> >
> >> > - doctype: The value of the PUBLIC
ID of the DOCTYPE
> declaration, if
> >> > any, used by the Consumer. Consumers using legacy
or strict style
> HTML
> >> > may supply the DOCTYPE. Producers MAY honor such
DOCTYPE while
> >> > generating markup.
> >> >
> >> > Document: WSRP1.0
> >> > Section: 5.1.10 MarkupType Type
> >> > Page: 20
> >> > Old Text:
> >> > New Text:
> >> >
> >> > [O] string doctypes[]
> >> >
> >> > - doctypes: An array of DOCTYPE
declarations that the Portlet
> can
> >> > support.
> >> >
> >> > Reasoning:
> >> >
> >> > Due to the legacy nature of web, some portal sites
are designed to
> >> > generate either or quirks mode HTML markup and
expect browsers to
> >> > interpret the markup accordingly. Browsers use
the HTML DOCTYPE
> >> > declaration to indicate browsers which mode to
use. For example,
> the
> >> > following DOCTYPE declaration can be used for
strict
> interpretation:
> >> >
> >> > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML
4.01//EN"
> >> > _"http://www.w3.org/TR/html4/strict.dtd"_
> >> <http://www.w3.org/TR/html4/strict.dtd>>
> >> >
> >> > During an earlier discussion, the following issues
have been
> identified:
> >> >
> >> > a. Consumers do not know whether a portlet can
generate markup in a
> >> > given DOCTYPE.
> >> > b. Portlets do not know what kind of DOCTYPE to
expect.
> >> >
> >> > The above changes address these issues. Please
note that, in order
> to
> >> > preserve backwards compat, both these elements
are optional, and
> the
> >> > behavior is unspecified when the doctypes are
not supplied by
> either
> >> side.
> >>
> >>
> >> To unsubscribe from this mailing list (and be removed
from the roster
>
> >> of the OASIS TC), go to
> >>
> _http://www.oasis-open.org/apps/org/workgroup/wsrp/members/leave_workgro
> up.php_.
> >>
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsrp-help@lists.oasis-open.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsrp-help@lists.oasis-open.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsrp-help@lists.oasis-open.org
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]