RE: building an object model of a XML schema

[Stuart Naylor <indtec@eircom.net>]

There has been a thread on this list about the language or origin of
element tags.
The answer for this seems to be that 'XML English' is currently more
prevalent so that is what should be used.
There are some people who actually believe markup might be hand written
and not just the output from created tools. Firstly both those I find
slightly absurd as for one thing English tags for any system my not have
direct and meaning full translations.

I don't want to discuss Human readable XML and constraints to English
tags.

What I do believe is the many questions on this list bring up much
evidence to XML Schema inadequacies. What I do hope is that XML schema
will be left as it is and not bastardised in a similar vain to HTML.
Data return in tagged pairs of small subsets of data is a perfect
application of XML schema.

Maybe 'object model' is the wrong terminology but I see some form of
Class and Sub Class structure being essential so that it is possible for
me to do a xmlschema.sanskrit.element and I can retrieve a singular
element without having to translate the British library for my single
element.

I guess the only reason I post on this forum is due to a wish to return
to XML's origin as unary global method of sending and receiving data.
XML schema unfortunately has an incorrect label as it sounds like it is
the be all and end all to XML. It should be given a pen name like the
plethora of alternatives out there such as Trex, Daml, RDF, OIL, Topic
maps, SOAP and the ridiculous amount of XML legacy systems out there. I
also deliberately say legacy systems as well because from what I see so
far the XML situation already has far more interoperability problems
than the binary standards that it is supposed to supersede.

RDF would seem to be the answer to most questions but with answers such
as <Peter>
Markup is yellow stickies stuck onto elements of information to identify
them, labelled accordingly.
</Peter>
Who knows.




-----Original Message-----
From: Jeff Lowery [mailto:jlowery@scenicsoft.com] 
Sent: Saturday, July 14, 2001 12:36 AM
To: 'Michael Brennan'; Jeff Lowery; Xml-Dev (E-mail)
Subject: RE: building an object model of a XML schema

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. 

------------------------------------------------------------------
The xml-dev list is sponsored by XML.org, an initiative of OASIS
<http://www.oasis-open.org>

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: xml-dev-request@lists.xml.org