[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]