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: building an object model of a XML schema

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

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

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.
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,
enough to XML Schema that would generate true XML Schema definitions,
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
data modeling language that I've seen, so if you took the XML-ness out
XML Schema you would have a decent start at a rich data constraint
with mutable datatypes. I like. Oh, and you could easily generate a
full-blown XML Schema from that abstract model language; and,
it has these archetypes that model ubiquitous object-model concepts
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
whose instances represent and manipulate the data model (I guess you'd
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

> 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,
every application and every language. When this becomes an unworkable
(becuase most of us, when left to our own devices, will do it wrong),
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
in the database world, IMHO, is that the object and relational models
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
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

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