Raphael,
I think I do understand what you mean.
> "Well-formed XML" simply implies that the output of the portlet will be
> parseable by an XML parser but does not enforce (or even expect) any
> DTD or schema compliance.
How on earth do you want to write a parser for a language that you don't
know. Leaving out the DTD only means that the portlet is not technically
bound, it would still need to compliant to some language. Unless --- unless
you are talking about different parsers for mime-type which the aggregation
module may be to handle.
But then, parsing the markup - even if it was well-formed - is an expensive
operation. I don't think we should enforce this burden onto the portal just
because we are not able to provide utility functions to do link substitution
in place (that is, right in the template). Also, you cannot leave this
decision open, because a portlet that relies on the portal to do certain
substitions would not run properly on a portal that goes for performace and
leaves everything through.
I think this discussion is crucial to the future of Jetspeed. Looking
forward to more arguments...
Thomas B.
----- Original Message -----
From: "Raphaël Luta" <[EMAIL PROTECTED]>
To: "JetSpeed" <[EMAIL PROTECTED]>
Sent: Wednesday, February 07, 2001 16:15
Subject: Re: Secure Portlets
At 15:05 07/02/2001 +0100, you wrote:
>Raphael,
>
> > 1- I still believe it's a bery bad idea not to impose a binding output
> > contract between the portlet and the container -> I'd like the API
> > to only allow well-formed XML document output in order to
> > make outpout post-processing as easy as possible (I thought last
> > time we discussed this that the consensus was in implementing this
> > restriction).
>
>There certainly wasn't consensus on the issue of an output contract. I am
>yet to see a convincing example of how such a contract should look like.
>A small example would be enough. Well-formed XML is *not* the
>answer to this particular problem. I am happy to repeat my 2 cents
>of reasoning for this:
>
>If the portal requires the portlet to adhere to a portal-set XML, then the
>portlet is severely limited as to what content it can display. This
approach
>may well work for news-type content, but it is not general-purpose. You
>can't apply the same DTD to news, wheather, mail, calendar, to-do, stock,
>and you name it.
>If on the other hand, the portal asks the portlet to return well-formed XML
>according to a DTD that the portlet defines, it would also have to return
>a number of stylesheets for processing. But who is saying that a portlet
>that doesn't behave with raw markup, suddenly does so when providing
>a stylesheet?
>Apart from that, writing a stylesheet is more difficult than creating plain
>markup. The argument you are giving for the bloated interface kind of
>applies to this issue as well then.
I think you're misreading what I wrote because of our last
ApacheCon discussions ;)
This has nothing to do with DTD and stylesheets.
"Well-formed XML" simply implies that the output of the portlet will be
parseable by an XML parser but does not enforce (or even expect) any
DTD or schema compliance.
My rationale for this is that I believe that, contrary to the servlet
container
which doesn't modify the servlet generated output, the portlet container
will often want to adapt & filter the produced content during the
aggregation
process (for example variable and link substituion in generated forms,
markup
stripping, output chunking, etc...).
If the API enforces that the output will be parseable, this will
dramatically reduce
the occurence of run-time errors because developpers will need to take care
of
what they generate.
If you consider our main target formats, they are all already XML based
(WML, VoxML,
SMIL, FO, etc...) except HTML, but producing XHTML instead of straight HTML
is not
too difficult and we can possibly provide some utility code that portlet
writers can use
in order to convert existing HTML to XHTML.
Now I agree, that restricting output to markup langages may be restrictive
since that
means no binary or plain text output. I see these as fringe cases since it
would be
very difficult to aggregate these kinds data by any means (and it's
certainly possible
to handle these situations by using DTD/schema aware adapters at the layout
engine
level).
--
Raphaël Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Services Manager / Paris
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
