[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Access Languages are Tied to Schemas
I have been searching for the properties that a repository access language must have. Here I present an argument for why an access language must be tied to a repository's architecture in the manner analogous to how SQL and OQL are tied to database schemas. I infer what this implies for XML DTDs and then ask a question whose answer I think has important repercussions. Let's say that a "repository" is any software object that contains information and that provides a way for clients to read, write, and modify that information. A client must know how to talk to the repository in order to get the repository to do anything. We'll call the language that the client must speak the "access language." The client uses this language to submit requests and to understand responses. The server uses this language to make sense of requests and to submit responses. Both the client and the repository must house knowledge of this access language. (The access language may use distinct subset languages for requests and responses, but both software objects would still have to contain knowledge of both subset languages. For simplicity, I assume that requests and responses use the same language, but my argument should hold even if they are different.) The access language must convey information in two directions. In order for the information to be comprehensible, it must be conveyed in recognizable units. Both the client and the repository must know how to generate and parse these units. Hence, a standard must exist to which both sides conform. This standard says what kind of information units there are and what they look like. Information units usually have relationships with one another. A client often cares about accessing units that have a particular relationship with some other unit. For example, a client might care to retrieve all liens on a particular property. The access language must allow a client to select units according to their relationships with other units. In particular, a client must be able to identify the relationships of concern. Both the client and the repository must now be in agreement about the kinds of relationships that may exist among information units. We find we also need a standard that says what kinds of relationships there are and what kinds of information units participate in them. It seems that the standard has quite a bit to say. It says what kinds of information units there are, what kinds of information they contain, what kinds of relationships there are, and what information units participate in those relationships. What we have is an object model. This is the kind of thing that OMT and UML are very good at expressing. We have learned that both the client and the repository must have knowledge of the same object model. Moreover, in the spirit of object-oriented design, each side should harbor some representation of this model. That is, both sides have components that share a common architecture. In retrospect, this makes sense. Were the two sides working with different models we'd have a case of the infamous impedance mismatch. We normally think of impedance mismatch as occurring between an object-oriented application and a relational database, but it can also occur between two object-oriented applications. One organization may decide that liens are not useful entities in themselves and so bottle them up with their associated properties (i.e. properties would be aggregates containing liens, and liens would not be classes of the schema). Another organization may want to store liens separately so that they can select all liens that meet a given criterion (i.e. properties would be associated with liens, and liens would be classes of the schema). When the second organization decides to hook its client up to the first organization's database, the client can neither select among liens nor properly interpret property objects. Okay, so we've established the need for industries to standardize on object models. These standard object models would only say what the repositories need to look like through an access language. Any given repository is free to transparently translate that model into a more suitable internal one. We've also established the need for access languages to reflect these object models. SQL and OQL conform to this requirement by having clients use the language of the database's persistent storage schema. XML introduces another way to model information, a way that is distinct from the relational approach but somewhat similar to the object-oriented approach. XML repositories have schemas too, and these schemas are defined by the DTDs. Before concluding I'd like to ask a question whose answer may have significant repercussions. It seems that by asking an XML repository to manage information for a particular industry, we are asking ourselves to create DTDs that model the industry. The question is this: to what extent are DTDs to specify the object model of a given industry? More specifically, do we intend for the following capabilities to fully implement an object model: (1) the ability of a repository to ensure that the information it contains is always in conformance with the DTDs, and (2) the ability of the clients to properly interpret the informational units and the relationships that the DTDs declare? In conclusion, it seems that that an access language must impose architectural constraints on at least a component of a repository and that these architectural constraints will apply to all repositories that conform to a particular industry standard. In particular, it does not seem possible to create individual access language protocols that won't to some degree constrain the architectures of the repositories. Such languages are probably feasible only when we can think of a repository as a flat file of unrelated information units. Since an object model will have to be developed for each industry, we might as well standardize on a way to access object models in general. This way we won't be asking industries to perform the additional work of inventing an access language for each object model. -- Joe Lapp (Java Apps Developer/Consultant) Unite for Java! - http://www.javalobby.org jlapp@a... xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|