[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]