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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: To Relax or not to Relax

[ Lists Home | Date Index | Thread Index ]
  • From: Jeff Lowery <jlowery@scenicsoft.com>
  • To: "'Rick JELLIFFE'" <ricko@geotempo.com>, xml-dev@xml.org
  • Date: Mon, 29 May 2000 12:17:21 -0700

Rick Jeliffe writes:
> The issue boils down, perhaps, to whether it is desirable to invent a
> new class of XML documents: ones which need to be "schema 
> processed" in
> order to be used. From a power and capability view, it would sure be
> nice--we can have XPaths which include type awareness (and then
> Schematron would inherit that!), XBase would know what 
> strings were URIs
> in documents, and so on.  But is this really creating an 
> overly-layered
> and bloated framework that will have performance problems over the WWW
> and which will create many excuses for dialects?  
> 
> But this new class of XML documents is where we may be heading.  

Rick,

I wonder if something more fundimental is happening. What I sense is the
pendulum swinging back from the tightly-bound data and methods of current
object-oriented methods to looser coupling of data and methods that have
existed before. XML facilitates this 'neo-traditional' approach because it's
heirarchical data structure can be easily mapped to methods in a
heirarchical class structure. Therefore, you have a data model and a methods
model.

The point is, is that it's easy to generate low-level accessors and mutators
based merely on the structure defined in the data model. Add a schema to the
mix, and you get type checking and cardinality validation, also. What's left
for the class method side of things is higher-level business rule functions
and dependency constraints.

What are the advantages? For one, many times you just need to transport the
data. Objects get in the way because of their binary nature. Also,
extracting the underlying data from an object requires some knowledge of
their APIs. When schemas are added to the data that's transported, apps
accepting that data alone (minus the higher-level methods) have at least
some hope of manipulating that data successfully given low-level set of
'ground rules' the schema defines.

There's another advantage: it's hard to write a set of methods for objects
that are flexible and generalizable enough to handle unknown variations in
the way data is manipulated for one purpose or another. Even within the same
industry, process varies widely whereas function remains the same. I see
data models as being closer to 'function' and objects tending be closer to
'process'. Therefore data models tend to remain stable over time, and it's
easier (though not easy) to come up with a data model that works across
process boundaries than it is to build an OO API that does the same.

My two cents,
	Jeff

***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS