Skip to main content

Identity constraint accessor/mutator generation

4 replies [Last post]
6111231
Offline
Joined: 2005-03-04
Points: 0

Hi! I have been working on some XML schemas to represent projections of object extents, and been looking into using identity constraints to model foreign keys/object references. Having a good programmer model for these seems to be a pretty basic construct in the binding model: I was encouraged to see that identity constraint support is a goal for JAXB2 and hence JAXRPC2. I was wondering if there has been any thought devoted to definining accessors/mutators for these references.

So for example if I have an XML schema for the following XML:

and I said in the XML schema that the @identity attributes were the keys and the @assignedto attribute was constrained to the set of project identity values through a keyref constraint called "resourceProject", it would be very very nice to my mind if the object generated for a resource had a mutable property "resourceProject" typed to the binding for projects.

This would help me make a fairly generic data access web service that could provide a reasonably idiomatic programmer model for accessing the result sets. Since I build prepackaged applications rather than a custom web service for a single set of use cases its hard for me to design services for all the possible programmer needs for our system, which is what is driving me to think in these general terms.

I didn't see any specific verbage in the JAXB2.0 early draft release that gave me any insight into how this might be handled.

Thanks for any insight you can provide,

Peter Wisnovsky

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
kohsuke
Offline
Joined: 2003-06-09
Points: 0

You are right that the current draft of JAXB 2.0 spec doesn't have any concrete description of how an identity constraint affects the data structure of the generated code.

The problem (for us) is that the identity constraints are so out-of-place with other schema definitions, and therefore it is somewhat difficult to make a meaningful/reliable inference about them.

Another goal of the JAXB 2.0 spec is to support the application-defined behaviors on top of the generated classes. Another way to achieve what you want is to use this and add those "look-up" as a behavior. Again the details aren't really decided yet, but in theory that should be also fairly simple.

6111231
Offline
Joined: 2005-03-04
Points: 0

Hmm. I'm not sure in what sense these are "out-of-place" with respect to other parts of XML schema. To my mind they close a critical lacuna in the coverage of the specification. Not having identity constraints is like UML with composite but not shared aggregation, or SQL without referential integrity. Our data model has literally hundreds of these relationships. As a packaged software vendor we can't design a custom service for each use case, so we have to approach the problem of providing an API from a more generic point of view. Having a general way to flatten data and modelling relations between items in different extents seems vital to us.

At the risk of drawing an invidious comparison, I observe that .NET generates a property on the source of such a relationship that traverses this identity constraint in their proxies (a "DataSet"). Cf.

REM projections is the outer scope that holds all the projections
Dim ps As projections
ps = New projections()

REM read in some sample data
ps.ReadXml("..\sample-data.xml")

REM traverse the timesheet table
Dim tss As projections.timesheetDataTable
tss = ps.Tables.Item("timesheet")
Dim ts As projections.timesheetRow
For Each ts In tss
Dim p As projections.projectRow

REM derefence the relationship from the timesheet to the project
p = ts.projectRow
Next

(Sorry, I know, "Ewww! VB code!")

This was derived from a model where a keyref was defined from timesheet to project, each of which have a key column. This seems very handy.

Peter

kohsuke
Offline
Joined: 2003-06-09
Points: 0

Identity constraints are out of place from the rest of the constraints, because for example the XPath isn't guaranteed to point to any particular element/attribute declaration. This means that without a heuristics, a compiler like XJC cannot generally determine what elements/attributes keys are pointing to, and so on. Also, keys can consist from multiple fields, which further complicates the binding. James Clark explains this more eloquently in http://www.idealliance.org/papers/xml2001papers/tm/web/05-01-03/relaxng.htm

This is very different from SQL, where it has a very solid and well-established mathmatics behind its model.

The point about .NET and DataSet is well taken, but I'm sure it also cannot handle identity constraints in more general cases.

I'd imagine that this kind of heuristics is difficult to specify. Perhaps we could consider a support as an RI extension to some simplistic cases like this.

6111231
Offline
Joined: 2005-03-04
Points: 0

Thanks for the info, that clarifies things. Indeed, I had observed that the MS support relies on the schema being laid out just so, as well as I see some additional element tagging in an MS specific namespace to annotate the set of extents as a "DataSet". As it happens this format is the one I had already been angling towards as being fairly natural for mapping a set of relational extents into XML as a set of SQL3ish tables (owned object graphs are inlined rather than broken into side tables). Another example of "embrace and extend" I guess, but perhaps illuminating from the point of view that MS has always had a good handle on the idea of tooling for applications over "rectangular" data, whether its from a relational DB or not. One might imagine building a JDBC XML rowset or J2EE Connector over this kind of XML file so consumers of the web service can use their data bound control experience to visually develop their applications. This is generally the kind of programmer I have in mind with my service...something like what I had chatted to some of the Rave group when I was at Sun :-)

Peter