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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Schemas Article

This happens to be a long mail --

I think the work on data models or rather the information in a document
with schema is still not very complete, it is quite an intriguing problem.
XPath 1.0 is well-defined (subset), and fairly complete, but i would
classify XQuery algebra as ongoing work.

i consider xml schemas as a *data modeling language*, i expect this to
happen -- most of the data in the world will be wrapped with an XML
wrapper, along with an xml schema. XML schemas provide regular expression
types (from XDuce), or more finely -- tree types and hedge types (hedge is
an ordered list of trees) -- the above along with also forest types
(forest is an unordered set of trees) will form a *very* complete data
model, in my opinion (though I do not care about forest types actually).

I am not very familiar with RDF, but in my opinion, RDF sits on top of xml
schemas, and actually is for a different purpose. I think it is more to
define semantics of much larger granularity than xml schemas, and
semantics that are typically not defined in xml schemas -- for example,
semantics like the who created a web page, or saying something like this
collection of web documents form a "community" -- so now search engines
can make use of such metalevel information for better results -- this is
building the semantic web...

We did try to use a web-centric approach for describing our services, but
a web-centric approach does not scale for sensor services well -- the
services present at any instant are very transitory, also what we need
more is a local service discovery protocol -- similar to what Jini
provides -- based on geographical proximity. We still do not use RDF
though -- it definitely seems useful for us to use RDF, but Jini templates
have been satisfactory so far.

For data, again, we need closure under union, just for describing the data
-- we have not thought about operations w.r.to the project, but again
there is no way out for us than to have closure under query operations.
The current state of the art, I believe, for defining query operations is
-- I *strongly* believe that we can define semantics for query operations
such that they will be closed under regular tree languages -- note that if
not regular tree languages, i am *very* sure we cannot define meaningful

Now for data storage, though the data model that the user sees will be
based on xml schemas, the storage will be in a relational database -- but
still, though there are tools available for doing that, I am not very
satisfied with the way union types expressed in an xml schema is handled
-- there is a way of normalizing and writing a regular tree grammar so
that "in effect" it has no union types (no | operator) -- i am very sure
this is the way of mapping from xml schemas to relational schemas --
inlining etc is good, but w/o a proper treatment of union types, it is
quite incomplete.

Now I will have to wait for operations to be defined, good semantics
defined, then try to complete the mapping from xml data model to
relational model by mapping the operations also.

I think that will mostly complete my thesis, unless my advisor comes up
with suggestions along the way. also all along the way, I should try to
convince people to first listen to what I have to say, and then try to
convince them why I believe in what I am saying... hmm, wonder how long it
is going to take if I have to try to do all of the above :) but it is
*very* interesting.

Finally to answer Len's question --
I believe xml schemas are for data modeling -- *numerous* gaps in data
modeling are filled by xml schemas. I think if we say data model, then
operations are an *inherent* part of it -- operations include simple
retrieval operations like projection -- w3c's proposal for xml-schema will
fail at the first operation itself.

I believe RDF will not meet my requirements because i think we are talking
of different things and definitely different granularity.

<warning>speaking for himself only</warning>

cheers and regards - murali.

On Fri, 8 Jun 2001, Bullard, Claude L (Len) wrote:

> I have not yet looked into RELAX/TREX deeply enough
> to compare.  Also, I don't have your deep knowledge
> of tree grammars.  Isn't the XQL work creating a
> data model to satisfy this requirement?
> Because this also came up on the HumanMarkup list,
> let me ask, do you consider xml-schemas a data modeling
> language or simply a way to define a data structure?
> Does that make a difference?  In other words, is
> it the application or the tool?  Would RDF meet
> your requirements?
> Len
> http://www.mp3.com/LenBullard
> Ekam sat.h, Vipraah bahudhaa vadanti.
> Daamyata. Datta. Dayadhvam.h
> -----Original Message-----
> From: Murali Mani [mailto:mani@CS.UCLA.EDU]
> Interesting. I also tend to believe that OOP is definitely *not* something
> which should be there from the beginning. And it is *impossible* to
> satisfy everyone with the set of constraints you provide.
> Let me ask how important are the following properties in favor of
> RELAX NG/RELAX/TREX over xml-schemas ---
> a) Query operations are a must for xml-schemas, actually for any data
> model. 1-unambiguity for any set of operators other than the usual regular
> expression operators (|, ,. *) have *never* been characterized. Without
> this characterization, it is impossible to do type inferencing for
> operations -- note that local tree grammars etc have been characterized,
> but it is the 1-unambiguity that has *never* been characterized.
> b) People do data integration -- for merger of companies etc, also for one
> project I work on -- a project on sensor networks, where services provided
> by sensors are *highly* transitory, and unpredictable. Data integration
> benefits *enormously* from closure under union -- actually otherwise, this
> problem is so difficult (trying to solve a problem with no solution except
> for uncharacterized special cases) that you will *never* be satisfied.