Hi Rainer, and all,
> we spent so much effort in designing the Criteria API in a typed way
> it feels a bit strange to see types and fields as free strings in the
XSD.
The proposal is to allow data access to clients that do not have or can
access the type system that defined the persistent domain objects. I am a
strong believer of strong typing :) But data could be made more widely
accessible if it deliberately loses its type constraints -- especially for
clients that either can not afford the constraints of a strongly typed
system, or do not care for warranties a strong type system provides. Many
popular data formats (e.g. JSON) are becoming ubiquitous in this
"schema-less" universe.
So, yes, this proposal is deliberately proposing to move the needle to the
opposite extreme of what JPA 2.0 did with Criteria Query API.
Further elaboration on how JPA can help data access for non-Java clients
can be found at this developerworks article [1].
[1]
http://www.ibm.com/developerworks/java/library/j-jest/?ca=drs-
Regards --
Pinaki
From: "Rainer Kwesi Schweigkoffer" <kwesi_at_sap.com>
To: Pinaki Poddar/Dallas/IBM_at_IBMUS
Cc: jsr338-experts_at_jpa-spec.java.net
Date: 05/26/11 12:13 PM
Subject: Re: [jsr338-experts] XSD for JPA Metamodel
Hi Pinaki, all,
Pinaki Poddar, am 25 May 2011 hast Du um 10:10 zum Thema "[jsr338-experts]
XSD for JPA Metamodel" geschrieben :
> The idea to express JPA metamodel as XML schema is to facilitate
> domain-invariant representation of persistent object graphs.
> SDO, as I understand, provides a domain-specific schema. Does not have
> explicit notions of id or version (that may have changed in newer
> versions).
Yes, you are right. However, we spent so much effort in designing the
Criteria API in a typed way that it feels a bit strange to see types
and fields as free strings in the XSD. That's why the idea of
expressing the domain in a PU specific XSD and having the XML follow
that XSD immediately popped into my mind. And from there to SDO the
step seems not to be too far. I just wanted to describe a risk one
might run into when proceeding further.
>
> Such a schema will help
> a) development of generic (as opposed to domain-specific) browser or
> query builder.
> and b) data exchange
> especially for non-Java clients.
>
> Other use case for such schema is REST based access to data, a topic
> which is gathering lot of interest in many quarters.
>
> I am *not* suggesting that a JPA provider provides facility to
> externalize the persistent object state. The XML schema exists for those
> who wants to build generic services on top of JPA.
Defining an XSD is one thing, where and when it should come into place
is another. What are your ideas about how the XML serialisation might
fit into the overall JPA picture ?
Kind regards
Rainer
---
Rainer Schweigkoffer SAP AG Walldorf
Business Solution & Technology TD Core JS&I
Technology Development Dietmar-Hopp-Allee 16
Java Server Core D-69190 Walldorf
JEE Implementation Group phone: +49 6227 7 45305
Building 3, I.3.14 fax: +49 6227 7 821177
rainer.schweigkoffer_at_sap.com
Sitz der Gesellschaft/Registered Office: Walldorf, Germany
Vorstand/SAP Executive Board: Werner Brandt, Angelika Dammann,
Bill McDermott (Co-CEO), Gerhard Oswald, Vishal Sikka,
Jim Hagemann Snabe (Co-CEO)
Vorsitzender des Aufsichtsrats/Chairperson of the SAP Supervisory
Board: Hasso Plattner
Registergericht/Commercial Register Mannheim No HRB 350269
Diese E-Mail kann Betriebs- oder Geschaeftsgeheimnisse oder sonstige
vertrauliche Informationen enthalten. Sollten Sie diese E-Mail
irrtuemlich erhalten haben, ist Ihnen eine Verwertung des Inhalts,
eine Vervielfaeltigung oder Weitergabe der E-Mail ausdruecklich
untersagt. Bitte benachrichtigen Sie uns und vernichten Sie die
empfangene E-Mail. Vielen Dank.
This e-mail may contain trade secrets or privileged, undisclosed, or
otherwise confidential information. If you have received this e-mail
in error, you are hereby notified that any review, copying, or
distribution of it is strictly prohibited. Please inform us
immediately and destroy the original transmittal. Thank you for your
cooperation.