xml-dev - Nested schemas

[Bryan Cooper <bryan.cooper@veritas.com>]

I am just starting with XML and appreciate this list.  Here's my
first 2 cents worth (ISDN dial up means it probably costs .003434 cents
except for the wasted time connecting)

I have some background with databases and text processing (troff project in
1982-
1984  and Tex in 1986-1988) and also distributed SQL databases (1988-1994)
and 
so I thought that XML has some very interesting features.  I am not sure where
some of the discussion on this list regarding semantics or theoretical
stuff is going to go but hey go for it if it helps your projects or the
language.

My take on XML at this stage is that it solves an age-old problem
for coding - the parser.  Its really a drag building ASCII/TEXT oriented
parsers for small utilities and the like.  So, first off XML is a generic
parser without YACC or more cryptic tools some of us have
scratched our heads over.

Some applications take parsers better than other.  That's just a fact
of information as far as my own personal experience has shown.   If
true, then XML is going to be more quickly adopted by applications which
in fact already have parsable information, such as HTML based, and
which are designed for one single function, such as displaying information.

In terms of nested schemas, a point to point type application, such
as one client - one database server, is probably going to be easier to use 
XML than  a distributed, multi-node application which requires integrating
several data sources simultaneously.  Embedding different types
of data from one app within other types of data from other apps
works better/easier for specific tasks such as displaying that data 
(HTML or other tagging document approaches)  
than it does for open-ended manipulating that data.  The reason is
we are ASSUMing that the data from different sources has 
some interrelationships with each other.

The reason it works well for display is that we're really only concerned
at this point with ONE application - the display of the information
from multiple sources.  Most applications know at least how to display
information, so that is a lowest common denominator function amongst many
many apps.

We really are not asserting that the information
is even coming from multiple sources - multiple physical locations,
sure under web approach.  But the generator of the information could
be just one application as far as the display application is concerned,
and its role is one specific task.  Other tasks like hyperlink are relatively
simple extensions to the display (here it comes) paradigm.   

Manipulating the information from multiple applications is a
huge step, since applications are still in their infancy 
regarding inter-relationships.  To this line of thinking,
using XML in the case of complex documents from multiple
applications is "merely" the formalization of the inter-relationship between
those applications. 

When and if there IS such an inter-relationship, it could be asserted that XML
would prove the formal rules do in fact apply and the inter-relationship
is proven.  If we are stating we want to create that inter-relationship
and XML is the method of externalizing that inter-relationship, then
that's a good first step.  Externalizing information relationships isn't
new to
information models but it also isn't easy.  Object models appear to
be more flexible but they still take a lot of work to be effective.

Any technique is inherently limited since we are formalizing something 
that may never have been formalized previously.  That doesn't mean 
the technique is inadequate - but it does mean the technique brings some
constraints that must be reflected somewhere - usually back in
the applications using the technique.  Nothing wrong in that.

So, where does that leave us with 'nested schemas'.  The first issue
I see is that the syntax may overlap between applications.  How
do we deal with that 'cause long term that will make XML a dead end for
anything like the lingua franca that some proponents are calling this
approach.  
The reason is that application development is still primarily done for
specific tasks and business issues  - the need to cross-boundaries
should be made easier by XML.  However, XML must then have
very simple techniques to support the different information models
it is parsing.

How do we ensure the parser is told to switch between 2 or more
different information parsers which use some common words in different
ways?  I think there's a need to resolve this issue - course I may have
missed the easy way to do that.    

I think there's enough brainpower out there to solve something
as basic as this.  If there are proposals already out there, can someone
summarize them with pointers to their design?  

My personal interest is in the combination of parseable information with
command driven applications.  CLI type utilities are prime candidates
for XML 'cause we can use XML syntax to join the CLI commands with the 
information required to be processed by the CLI.

XML doesn't directly support an event driven application syntax.
To my mind, it would require built-in XML event blocks for the parser so that
the parser could in fact be data-driven to interoperate with the application
more easily.  I see the parser currently as query driven from the application,
where the parser is expected to read in a "document" as one block and then
it is broken down into the tagged components.

It would be interesting to see how XML could be used instead to
inter-operate between the parser and the application where there were
staged parsing based upon information within the information.
This extension would need to be supported in the DTD so people
could easily tell the XML parser when and where to breakdown the
information.  

In general, XML enhancements need to focus on how to improve the
parser.  We need more than ELEMENTS and ATTRIBUTES as fundamental
parser controls if the basic parser is going to be improved to support
a wider range of applications.  I'd like to see EVENTS discussed in relation
to nested schemas for example to help the parser switch schemas.   
We need to look as whether issues like  nested schemas is really leading us 
toward something more powerful for the  parser and therefore more helpful to 
alot more applications.

Thanx and I look forward to reading more about specific XML application
development problems.

...bryan

F. Bryan Cooper	 		707 823 7324 
VERITAS Software      		707 321 3301 mobile
Bryan.Cooper@veritas.com   

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