[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Request for a poll: (was RE: Datatypes vs anarchy)
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: Rick Jelliffe <firstname.lastname@example.org>,Ronald Bourret <email@example.com>, xml-dev <firstname.lastname@example.org>
- Date: Thu, 15 Mar 2001 09:09:21 -0600
Urrp. That is PRECISELY what bedevils X3D
and it was brought up several times by
different sources during the XML Schema work.
We did a long thread on the power and ways
of groves as a result. Henry says,
"almost but not quite groves". VRML has
the problem of orignally defining the
abstract node/fields in the same syntax
as the actual instance language. That
made it difficult when the time came
to add an XML syntax. The problem can't
be succinctly stated:
o One abstract object model; multiple syntaxes.
It has become madness and split the VRML
efforts cleanly into multiple efforts
(X3D, RM3D) and diverging models.
Why? XML isn't just syntax. It has an explicit
element/attribute separation of namespace.
Elements can have have attributes. Attributes
can't have elements as children. VRML97
has nodes/fields. Children fields can
have nodes. Groves could handle that
fine. XML can't. The bedevilment was
to make a clean map, we needed the
wrapper elements to emulate some of
the fields (eg, children). To an
XMLer, it looks silly because XML
doesn't need those.
So what you are suggesting looks right,
but I contend we are just going right
back down the same path the groves
guys went down. Nodes is nodes,
properties is properties, someone
Intergraph Public Safety
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Rick Jelliffe [mailto:email@example.com]
Yes. And there is a nice design issue here for the future too:
Perhaps what we need for a schema language is something along the lines of
In XML Schemas, we have found all sorts of nice abstractions (components)
for what goes on in a language. Yet the conceptual modeling people (I think
Robin Cover and Peter Chen might concur) think that the bottom-up approach
That is why, to jump on my hobbey-horse, I don't see that we need more
grammar-based schema languages (not to say that we shouldn't continue to
perfect and mate existing ones). Instead, we need to start thinking about
what schema languages would be needed to implement the above kind of schema.
Personally, I think that a schema language made from ER for the conceptual
model and a Schematron-like language to do the language binding might be a
nice fit (if Schematron-like languages can be extended to act generatively.)