[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: a or b or both - mystery..
- From: Murali Mani <mani@CS.UCLA.EDU>
- To: Marcus Carr <firstname.lastname@example.org>
- Date: Tue, 17 Apr 2001 00:55:52 -0700 (PDT)
I think TREX is largely motivated to allow people to express what they
want more easily -- in short, it has so few restrictions that we do not
have to worry whether our schema is correct or not. I think almost all
other schema languages have more restrictions than TREX.
But I think RELAX has its own advantages -- it clearly separates "types"
that produce trees, and types that produce "hedges" - hedge is an ordered
list of trees (Makoto is the expert in this field). I think this
separation is very clean.
I have asked professors and others -- everyone I have asked believes
things just will not work without closure - you will get unexpected
things. I think if you use XML only for data exchange, then closure does
not matter, but if you want to do actual processing, then I think closure
is *very* important. If I am right, a good example of a simple query that
is not closed for XML schemas is given in the reference. In short,
non-closure I think is a *very* serious issue -- I have verified with a
few XML people also, but still I am not sure if there is universal
consensus that closure is very important. Regarding the project that I
work on, I do *union* of schemas *vigorously* -- for RELAX union is very
clearly defined, I am not sure whether it will ever be possible to define
a meaningful union for XML Schema.
It might be possible to get a very good closed set of operations for XML
Schema, but I doubt it very much. This is based on what I have seen so
far, and based on history. I say history because languages such as RELAX
and TREX form regular tree languages, and they are studied from late
1950's -- they are *very* well studied.
And it was a pleasure trying to explain whatever I know. I think everyone
in this group tries to learn from the other. Also this mailing list helps
a lot in trying to understand XML as a group.
I have tried my bit before to persuade XML Schema to consider regular tree
languages, but I think they might not have -- so to get a clear picture,
we probably should get the views of the XML Schema WG also.
<warning>speaking for himself only</warning>
cheers - murali.
On Tue, 17 Apr 2001, Marcus Carr wrote:
> Murali Mani wrote:
> Is "ease of use" the main motivation for allowing non-deterministic
> models in TREX? As these problems seem even less frequent in XML than
> they did in SGML, this seems not to buy a whole lot.
> > PS: The issues are not just expressiveness when you get to document
> > processing, but closure properties are *very* important, and it gets
> > really messy as XML Schema is *not* closed under 99% of the operations
> > that anyone will need.
> You clearly understand this stuff a lot better then I do, so please
> interpret any questions as curiousity rather than a challenge to your
> points. To whom are closure properties important? What proportion of
> developers will be impacted by the lack of closure, and what will the
> ramifications be? Do the restrictions on queries due to lack of
> closure result in processing inefficiencies, or something more dire?
> Would you term this as a wide issue, or a narrower one that you're
> looking at very closely?
> > I am not sure whether I should give this, but I think this is a decently
> > prepared report, written largely by my friend, but it is my work also, I
> > think some people might find it useful -- it is available at
> > http://www.cs.ucla.edu/~mani/xml/papers/conferences/WebDB2001/td-main2.ps
> It looks very interesting, but it would help me if I understood the scope of the
> issues better. Thanks for your patience.
> Marcus Carr email: email@example.com
> Allette Systems (Australia) www: http://www.allette.com.au
> "Everything should be made as simple as possible, but not simpler."
> - Einstein
> The xml-dev list is sponsored by XML.org, an initiative of OASIS
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: firstname.lastname@example.org