OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sdo message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [sdo] [SDO-47]: Problems maintaining multiple specificationdocuments



Geoff Winn [25/Jan/07 11:28 AM] 
By way of an experiment, I tried using a freeware tool to convert
chapter 1 of the V2.1 Java spec into Latex format. The resulting markup
file is attached (the .tex one). I also processed that to generate .pdf
and that is attached too. The result is certainly not ideal, however
this conversion required no human intervention at all and is still
useable, if a bit untidy. I think the format issues could be fixed in
the .tex source fairly easily.

This is not an urgent issue for V3, however I think we do need to
resolve whether we persist with Microsoft Word before we resume changing
the document.

I chose to use Latex because a) I happen to know it and b) it's free.
However, any similar markup tool would likely be as good or maybe
better.


Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

Java-SDO-Spec-v2.1.0-FINAL_ch1.pdf

\documentclass[12pt]{article}
\usepackage{makeidx}
\usepackage{multirow}
\usepackage{multicol}
\usepackage[dvipsnames,svgnames,table]{xcolor}
\usepackage[dvips]{graphicx}
\usepackage{ulem}
\usepackage{hyperref}
\author{Shawn Moe}
\title{SDO2.1 specification}
\setlength{\paperwidth}{612pt}
\setlength{\paperheight}{792pt}
\setlength{\textheight}{648pt}
\setlength{\textwidth}{432pt}
\setlength{\voffset}{-72pt}
\setlength{\hoffset}{-72pt}
\setlength{\evensidemargin}{90pt}
\setlength{\oddsidemargin}{90pt}
\setlength{\topmargin}{39pt}
\setlength{\headheight}{13pt}
\setlength{\headsep}{20pt}

\makeatletter
	\newenvironment{indentation}[3]%
	{\par\setlength{\parindent}{#3}
	\setlength{\leftmargin}{#1}       \setlength{\rightmargin}{#2}%
	\advance\linewidth -\leftmargin       \advance\linewidth -\rightmargin%
	\advance\@totalleftmargin\leftmargin  \@setpar{{\@@par}}%
	\parshape 1\@totalleftmargin \linewidth\ignorespaces}{\par}%
\makeatother 

% new LaTeX commands
\newcommand{\styleCode}[1]{{\footnotesize \texttt{#1}}}
\newcommand{\styledateOne}[1]{\fcolorbox[HTML]{BBBBBB}[HTML]{F0F0F0}{\textcolor[HTML]{336699}{#1}}}
\newcommand{\styleDefaultText}[1]{#1}


\begin{document}
Service Data Objects For Java Specification

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Version 2.1.0, November 2006
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\large Authors}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Matthew
Adams\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}Xcalia
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Cezar
Andrei\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}BEA
Systems, Inc.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Ron Barack\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}SAP AG
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Henning Blohm\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}SAP
AG
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Christophe
Boutard\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}Xcalia
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Stephen Brodsky\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}IBM
Corporation
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Frank Budinsky\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}IBM
Corporation
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Stefan
B\"{u}nnig\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}SAP AG
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Michael
Carey\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}BEA
Systems, Inc.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Blaise
Doughan\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}Oracle
Corporation
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Andy
Grove\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}Rogue
Wave Software
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Omar
Halaseh\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}Oracle
Corporation
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Larry
Harris\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}Oracle
Corporation
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Ulf von
Mersewsky\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}SAP
AG
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Shawn Moe\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}IBM
Corporation
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Martin Nally\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}IBM
Corporation
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Radu
Preotiuc-Pietro\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}BEA
Systems, Inc.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Mike
Rowley\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}BEA
Systems, Inc.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Eric
Samson\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}Xcalia
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
James
Taylor\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}BEA
Systems, Inc.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Arnaud
Thiefaine\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}\hspace{15pt}Xcalia
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

Copyright Notice

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
\textcopyright{} Copyright BEA Systems, Inc., International Business
Machines Corp, Oracle, Primeton Technologies Ltd, Rogue Wave Software,
SAP AG., Software AG., Sun Microsystems, Sybase Inc., Xcalia, Zend
Technologies, 2005, 2006. All rights reserved.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
.
\end{indentation}
}



License

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
The Service Data Objects Specification is being provided by the
copyright holders under the following license. By using and/or copying
this work, you agree that you have read, understood and will comply
with the following terms and conditions:
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Permission to copy, display and distribute the Service Data Objects
Specification and/or portions thereof, without modification, in any
medium without fee or royalty is hereby granted, provided that you
include the following on ALL copies of the Service Data Objects
Specification, or portions thereof, that you make:
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
1. A link or URL to the Service Data Objects Specification at this
location:
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
http://www.osoa.org/display/Main/Service+Data+Objects+Specifications
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
2. The full text of this copyright notice as shown in the Service Data
Objects Specification.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
BEA, IBM, Oracle, Primeton Technologies, Rogue Wave Software, SAP,
Software AG, Sun Microsystems, Xcalia, Zend Technologies (collectively,
the \textquotedblleft{}Authors\textquotedblright{}) agree to grant you
a royalty-free license, under reasonable, non-discriminatory terms and
conditions to patents that they deem necessary to implement the Service
Data Objects Specification.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
THE Service Data Objects SPECIFICATION IS PROVIDED "AS IS," AND THE
AUTHORS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED,
REGARDING THIS SPECIFICATION AND THE IMPLEMENTATION OF ITS CONTENTS,
INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS
FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT OR TITLE. THE AUTHORS WILL
NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR
CONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR
DISTRIBUTION OF THE SERVICE DATA OBJECTS SPECIFICATION.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
The name and trademarks of the Authors may NOT be used in any manner,
including advertising or publicity pertaining to the Service Data
Objects Specification or its contents without specific, written prior
permission. Title to copyright in the Service Data Objects
Specification will at all times remain with the Authors.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
No other rights are granted by implication, estoppel or otherwise.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
{\large \textbf{Status of this Document}}
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
This specification may change before final release and you are
cautioned against relying on the content of this specification. The
authors are currently soliciting your contributions and suggestions.
Licenses are available for the purposes of feedback and (optionally)
for implementation.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
BEA is a registered trademark of BEA Systems, Inc.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
IBM is a registered trademark of International Business Machines
Corporation in the United States, other countries, or both.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Oracle is a registered trademark of Oracle USA, Inc.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Rogue Wave is a registered trademark of Quovadx, Inc
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
SAP is a registered trademark of SAP AG.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Software AG is a registered trademark of Software AG
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Sun and Sun Microsystems are registered trademarks of Sun
Microsystems, Inc.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Sybase is a registered trademark of Sybase, Inc.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Zend is a trademark of Zend Technologies Ltd.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Java and all Java-based trademarks are trademarks of Sun Microsystems,
Inc. in the United States, other countries, or both.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Other company, product, or service names may be trademarks or service
marks of others.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{-36pt}{0pt}

\end{indentation}
}

\begin{center}
\begin{indentation}{0pt}{-36pt}{0pt}
\textbf{{\LARGE Table of Contents}}
\end{indentation}
\end{center}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
\tableofcontents
\end{indentation}
}

\section{\textsf{Introduction}}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Service Data Objects (SDO) is a data programming \textbf{architecture}
and an \textbf{API}.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
The main purpose of SDO is to simplify data programming, so that
developers can focus on business logic instead of the underlying
technology.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
SDO simplifies data programming by:
\end{indentation}
}

\begin{itemize}
	\item unifying data programming across data source types
	\item providing support for common application patterns
	\item enabling applications, tools and frameworks to more easily query,
view, bind, update, and introspect data.
\end{itemize}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
For a high-level overview of SDO, see the white paper titled
\textquotedblleft{}Next-Generation Data Programming: Service Data
Objects\textquotedblright{} \cite{ref3}
%[3]
.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

\subsection{\textsf{Key Concepts}}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
The key concepts in the SDO architecture are the \textbf{Data Object},
the\textbf{ data graph }and\textbf{ } the \textbf{Data Access Services
(DAS)}.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
A Data Object holds a set of named properties, each of which contains
either a simple data-type value or a reference to another Data Object.
The Data Object API provides a dynamic data API for manipulating these
properties.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
The data graph provides an envelope for Data Objects, and is the
normal unit of transport between components. Data graphs can track
changes made to the graph of Data Objects. Changes include inserting
Data Objects, deleting Data Objects and modifying Data Object property
values.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Usually, data graphs are constructed from one of the following:
\end{indentation}
}

\begin{itemize}
	\item Data sources
\begin{itemize}
	\item such as XML files, Enterprise Java$^{TM}$ Beans (EJBs), XML databases
and relational databases.
\end{itemize}

	\item Services
\begin{itemize}
	\item such as Web services, Java Connector Architecture (JCA) Resource
Adapters and Java Message Service (JMS) messages.
\\

\end{itemize}

\end{itemize}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
Components that can populate data graphs from data sources and commit
changes to data graphs back to the data source are called Data Access
Services (DAS). The DAS architecture and APIs are outside the scope of
this specification.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

\subsection{\textsf{Requirements}}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
The scope\label{change_history} of the SDO specification includes the
following requirements:
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

\begin{enumerate}
	\item \textbf{Dynamic Data API.} Data Objects often have typed Java
interfaces. However, sometimes it is either impossible or undesirable
to create Java interfaces to represent the Data Objects. One common
reason for this is when the data being transferred is defined by the
output of a query. Examples would be:
	\item A relational query against a relational persistence store.
	\item An EJBQL queries against an EJB entity bean domain model.
	\item Web services.
	\item XML queries against an XML source.
	\item When deployment of generated code is not practical.
\end{enumerate}

{\raggedright
\begin{indentation}{36pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{36pt}{0pt}{0pt}
In these situations, it is necessary to use a dynamic store and
associated API. SDO has the ability to represent Data Objects through a
standard dynamic data API.
\\

\end{indentation}
}

\begin{enumerate}
	\item \textbf{Support for Static Data API.} In cases where metadata is known
at development time (for example, the XML Schema definition or the SQL
relational schema is known), SDO supports code-generating interfaces
for Data Objects. When static data APIs are used, the dynamic data APIs
are still available. SDO enables static data API code generation from a
variety of metamodels, including:
	\item Popular XML schema languages.
	\item Relational database schemas with queries known at the time of code
generation.
	\item Web services, when the message is specified by an XML schema.
	\item JCA connectors.
	\item JMS message formats.
	\item UML models
\end{enumerate}

{\raggedright
\begin{indentation}{36pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{36pt}{0pt}{0pt}
While code-generation rules for static data APIs is outside the scope
of this core SDO specification, it is the intent that SDO supports
code-generated approaches for Data Objects.
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

\begin{enumerate}
	\item \textbf{Complex Data Objects.} It is common to have to deal with
\textquotedblleft{}complex\textquotedblright{} or
\textquotedblleft{}compound\textquotedblright{} Data Objects. This is
the case where the Data Object is the root of a tree, or even a graph
of objects. An example of a tree would be a Data Object for an Order
that has references to other Data Objects for the Line Items. If each
of the Line Items had a reference to a Data Object for Product
Descriptions, the set of objects would form a graph. When dealing with
compound data objects, the change history is significantly harder to
implement because inserts, deletes, adds, removes and re-orderings have
to be tracked, as well as simple changes. Service Data Objects support
arbitrary graphs of Data Objects with full change summaries.
\end{enumerate}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

\begin{enumerate}
	\item \textbf{Change Summary.} It is a common pattern for a client to
receive a Data Object from another program component, make updates to
the Data Object, and then pass the modified Data Object back to the
other program component. To support this scenario, it is often
important for the program component receiving the modified Data Object
to know what modifications were made. In simple cases, knowing whether
or not the Data Object was modified can be enough. For other cases, it
can be necessary (or at least desirable) to know which properties were
modified. Some standard optimistic collision detection algorithms
require knowledge not only of which columns changed, but what the
previous values were. Service Data Objects support full change summary.
\end{enumerate}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

\begin{enumerate}
	\item \textbf{Navigation through graphs of data.} SDO provides navigation
capabilities on the dynamic data API. All Data Objects are reachable by
breadth-first or depth-first traversals, or by using a subset of XPath
1.0 expressions.
\end{enumerate}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

\begin{enumerate}
	\item \textbf{\label{Metadata}Metadata.} Many applications are coded with
built-in knowledge of the shape of the data being returned. These
applications know which methods to call or fields to access on the Data
Objects they use. However, in order to enable development of generic or
framework code that works with Data Objects, it is important to be able
to introspect on Data Object metadata, which exposes the data model for
the Data Objects. As Java reflection does not return sufficient
information, SDO provides APIs for metadata. SDO metadata may be
derived from:
	\item XML Schema
	\item EMOF (Essential Meta Object Facility)
	\item Java
	\item Relational databases
	\item Other structured representations.
\end{enumerate}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

\begin{enumerate}
	\item \textbf{Validation and Constraints.}
	\item Supports validation of the standard set of constraints captured in the
metadata. The metadata captures common constraints expressible in XML
Schema and relational models (for example, occurrence constraints).
	\item Provides an extensibility mechanism for adding custom constraints and
validation.\label{relationships}
\end{enumerate}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

\begin{enumerate}
	\item \textbf{Relationship integrity.}
	\item An important special case of constraints is the ability to define
relationships between objects and to enforce the integrity of those
constraints, including cardinality, ownership semantics and inverses.
For example, consider the case where an employee has a relationship to
its department and a department inversely has a list of its employees.
If an employee's department identifier is changed then the employee
should be removed, automatically, from the original department's list.
Also, the employee should be added to the list of employees for the new
department. Data Object relationships use regular Java objects as
opposed to primary and foreign keys with external relationships.
	\item Support for containment tree integrity is also important.
\end{enumerate}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
\textbf{NOTE} the following areas are out of scope:
\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

\begin{enumerate}
	\item \textbf{Complete metamodel and metadata API.} SDO includes a minimal
metadata access API for use by Data Object client programmers. The
intention is to provide a very simple client view of the model.  For
more complete metadata access, SDO may be used in conjunction with
common metamodels and schema languages, such as XML Schema \cite{ref1}
%[1]
and the EMOF compliance point from the MOF2 specification \cite{ref2}
%[2]
. Java annotations in JSR 175 may be a future source of metadata.
\\

	\item \textbf{Data Access Service (DAS) specification.} Service Data Objects
can be used in conjunction with \textquotedblleft{}data
accessors\textquotedblright{}. Data accessors can populate data graphs
with Data Objects from back-end data sources, and then apply changes to
a data graph back to a data source. A data access service framework is
out of scope but will be included in a future Data Access Service
specification .
\end{enumerate}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

\subsection{\textsf{Organization of this Document}}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}
This specification is organized as follows:
\\

\end{indentation}
}

\begin{itemize}
	\item \textbf{Architecture}: Describes the overall SDO system.
	\item \textbf{Java API}: Defines and describes the Java API for SDO.
	\item \textbf{Generating Java from XML Schemas}: Shows how Java is generated
from XML Schemas (XSD).
	\item \textbf{Java Interface Specification}: Defines how Java interfaces are
generated and used.
	\item \textbf{Java Serialization of DataObjects}: Defines how to serialize
DataObjects.
	\item \textbf{SDO Model for Types and Properties}: Shows the SDO Type and
Property in model form.
	\item \textbf{Standard SDO Types}: Defines and describes the Standard SDO
Types.
	\item \textbf{XML Schema to SDO Mapping}:  Defines and describes how XML
Schema declarations (XSD) are mapped to SDO Types and Properties.
	\item \textbf{Generation of XSD from SDO Type and Property}: Describes how
to generate  XSDs from SDO Types and Properties.
	\item \textbf{XPath Expression for DataObjects}: Defines an augmented subset
of XPath that can be used with SDO for traversing through Data Objects.
	\item \textbf{Examples}: Provides a set of examples showing how SDO is used.
	\item \textbf{DataType Conversion Tables}: Shows the set of defined datatype
conversions.
\end{itemize}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

{\raggedright
\begin{indentation}{0pt}{0pt}{0pt}

\end{indentation}
}

\end{document}


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]