Access Languages are Tied to Schemas

[Lauren Wood]

> From:          Joe Lapp <jlapp at acm.org>

> 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. 

A nice summary of what the principles of the DOM are all about - 
defining an interface in a language-independent way that clients and 
hosts can implement without necessarily implementing any given 
underlying representation of the information. So the DOM is not 
really properly named, since it's really the specification of the 
interface rather than the object model that we are concerned with. 

> 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?

One example (though not the only possible) is in the DOM work, which 
has three parts.
1) core - this contains the general methods, functions, definitions 
which are applicable to HTML and XML documents, e.g., what is a Node,
how is an element represented, how does an attribute relate to the 
element it is attached to, etc.
2) HTML -this knows the HTML DTD and therefore can build on top of 
the DOM core with functions specific to that DTD
3) XML - this contains the stuff that HTML doesn't need that is in 
XML, such as CDATA sections

I could imagine industry-specific versions of part 2), that build on 
the DOM core to add DTD-specific functionality for that industry.

> 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.

I think it is possible to build a general API for XML documents, so 
if one of your imposed requirements on a repository is that it be in 
XML, and a general solution would not require that, then I agree. I 
do not agree that an object model must be developed for each industry 
- if the access method is standard, then whichever underlying model 
of the information a given tool uses doesn't really matter. It will 
have implications in performance etc, but it should be possible to 
implement the interfaces if they have been reasonably defined. 


cheers,

 
Lauren

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)