[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: building an object model of a XML schema
- From: Jeff Lowery <jlowery@scenicsoft.com>
- To: 'Michael Brennan' <Michael_Brennan@allegis.com>,Jeff Lowery <jlowery@scenicsoft.com>,"Xml-Dev (E-mail)" <xml-dev@lists.xml.org>
- Date: Fri, 13 Jul 2001 16:36:12 -0700
Well, I read you post and I fail to see the disagreement (this happens
between me and Len all the time). So allow me to clarify:
> > Right now, that information is missing from XML Schema, and
> > various code
> > generation implementations have their own unique ways of adding the
> > information. As it should be? I hope not.
>
> Actually, I would not want to see that in XML Schema. If XML
Missing was the wrong term; how about "rightfully absent from"? I'm not
proposing adding anything to XML Schema; there's plenty there already.
But people do decorate the XML Schema definitions in order to generate
efficient data manipulation objects from them. The nasty is that it's
language-specific. What I would like is a data modeling language, similar
enough to XML Schema that would generate true XML Schema definitions, yet
also include means for mapping efficiently to an abstact OO langauge.
> Actually, I would not want to see that in XML Schema. If XML
> Schema were
> intended as a data modelling language, rather than as a
> "foundation" spec
> for other XML specs, I wouldn't have a problem with this. But
I agree. But there is funcitonality in XML Schema that is absent from any
data modeling language that I've seen, so if you took the XML-ness out of
XML Schema you would have a decent start at a rich data constraint language,
with mutable datatypes. I like. Oh, and you could easily generate a
full-blown XML Schema from that abstract model language; and, incidentally,
it has these archetypes that model ubiquitous object-model concepts which,
when you map abstract data model datatypes to the archetypes, you can
generate both a useful XML Schema (or DTD, or RELAX NG) and some object code
whose instances represent and manipulate the data model (I guess you'd have
to tie-in target data model to target object model somewhere). It would
eliminate the need for my skill set, I could find a less demanding work
elsewhere, you wouldn't have to read this nonsense, and we'd all be happy.
Whee.
>
> Note, that it is also possible to annotate an XML Schema with
> attributes and
> elements from other namespaces. You can add application
> specific info to the
> model to suit your needs in a way that is compatible with other schema
> processors (they can ignore your application specific info).
Well, it's being done, I'm sure, but also being reinvented everywhere, for
every application and every language. When this becomes an unworkable mess
(becuase most of us, when left to our own devices, will do it wrong), then
we will say: "Hey! There's got to be a better way." And then we can talk
about this in earnest once more. The only reason this idea hasn't succeeded
in the database world, IMHO, is that the object and relational models are
too different to map the two automagically. Hierarchical data models
simplify the problem much, methinks.
> You can also do
> this with RELAX NG. This is a sound approach, IMHO, to let
> users extend the
> model in useful ways without the core XML Schema grammar having to
> accomodate everyone's use case.
Yeah, but even in the data model I vaguely envision, you wouldn't pay for
what you didn't use. I think that's a pattern, even.