Re: Goal: POJO-based

From: Dhanji R. Prasanna <>
Date: Mon, 23 Apr 2007 20:34:55 +1000


This sounds like it's shaping up to be a religious debate, so I'll be brief

Maybe I am missing something but how do you define a contract language
without a grammar (schema) and a release specification (version)?
"application/xml" is a great example of an API-neutral contract, as are
"text/html", "application/ms-word" and several others. My point is, Jsr311
doesn't (and shouldn't) care what the transmission content looks like,
beyond the user-provided (or default) plugins for marshalling and
unmarshalling those types.

In that vein binding to xml as [the "standard"] transport medium is as bad
as binding to a language dependent medium like java/rmi. Anyway I suspect we
are saying the same thing in different ways (I hope =)



On 4/23/07, Julian Reschke <> wrote:
> Dhanji R. Prasanna wrote:
> > Hao,
> >
> > I am with Jerome on this. I dont really see how representational state
> > can leak java idioms--can you give us any examples? I really dislike the
> > idea of contract-first programming (we're back to SOA and wizdull).
> >
> > Also xml is not a platform or language-independent medium. When you
> > convert something to xml, you're dependent on xml and all the problems
> > it entails (schema, versioning, legacy dtds...). The advantage of
> > API-neutral web services (a la RESTful web-services) is that we have no
> > such dependence (except on the web and its idioms--i.e. http and http
> > methods). It's conceivable that a web service is consumed as Json, html,
> > or raw formats (like fastinfoset or jpeg). I would hate to think
> > everything is converted to text/xml as an intermediary! =)
> >
> > Dhanji.
> I do agree that we should allow multiple representations, and not rely
> on application/xml (hint hint) alone. I disagree that using XML makes us
> dependant on schemas or DTDs. XML works very well without grammar
> information (at runtime). I also disagree that format versioning is an
> issue specific to XML.
> Best regards, Julian
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail: