[
Lists Home |
Date Index |
Thread Index
]
> > That's a bit of a strawman, IMHO. It may have been the
> intent of the WG to
> > produce OO in XML, but regardless it seems natural to
> associate a collection
> > of properties with a concept.
>
> XML has neither the concept of properties nor the concept of
> concept. ;) I
> do know a language that has these concepts though.
Let's not argue semantics while arguing semantics, okay? I'm talking about
schema languages, not data. Data must be assigned types though a (schema)
mechanism. Same with XML as with object instances as with values in database
table rows. The data does not define its type.
> > C++. So there may be a tight corrollary between methodless
> public structs
> > in C++ (or methodless classes with public data members in
> Java) and XML.
> > Both associate fields with types. What's a type? Well,
> that's another
> > lengthy thread so I won't go there.
>
> XML associates fields with types? Where do you see anything
> like that in
> the XML specification. The closest thing to "field" in XML is
> attribute.
> But we've been talking about element content.
Again, do you want to talk about XML or schemas for XML? It thought we were
discussing the latter.
I'm not saying that an XML element or attribute has to be assigned a type.
Yes, you can treat them purely syntactically. But if that XML is a
serialization of, say, an object's data, then in many cases it will be
useful to convey datatype information somehow. Other's may want to chuck all
that nasty datatype information out, and treat the XML data as patterns.
It's okay, but I think something's getting lost there. Losing information is
not always a handy thing.
> > > Does
> > > your relational
> > > schema map from relations into objects?
> >
> > No, but a normalized relational schema defines domains,
> represented by
> > tables. Domains are the spittin' cousins of types.
>
> Relational schemas are optimized for speed of lookup. Objects are
> optimized for ease of programming. XML is optimized for ease
> of reading
> and writing (as a serialization format!). Mapping between the
> worlds is
> possible but it will usually involve a process of defining
> the mapping!
Let's be sure we're not equating physical data models with conceptual ones.
There are data models in the abstract. It's nice when you can convert an
abstract model in to a physical one, but often you have to compromise in the
process. Some of those compromises may involve optimization, encoding, and
ease of maintenance. None of these invalidates the conceptual model, though.
It's perfectly possible to build an abstract object model implemented in
relational schemas. I worked four years on a project that did just that.
'Twern't easy, but it can be done. And the resulting relational models were
fully normalized and performed respectably. The same object model was also
converted to classes, and the twain physical models were joined. I'm not
going to say the result was perfection codified, but given a enough monkeys
and keyboards....
Granted, your and I are debating schemas (WXS, DTD, RELAX NG) for physical
data XML representations. But converting one physical model to another of a
different _conceptual_ type (implemented physically) I believe involves some
abstractions. It's figuring out which abstractions are useful that's the
trick. I see some of these abstractions in xbind, and I see them in Castor
as well.
Anyway, I'm losing the thread of the argument, but there was a point in
there somewhere. See if you can find it, I'm not sure where it went...
> > But it seems that such an approach would immediately be
> abstracted away with
> > some syntactic sugar, right? You want to hand type an AF
> mapping instead of
> > typing "base="? Evidently your keyboard doensn't have a
> hole worn in the
> > middle of the backspace key like mine does.
>
> An AF mapping does not involve that much more typing than
> base=. But it is
> more flexible because you a third party can define the mapping from
> subtypes to supertypes.
That's fine. I just don't want to be typing the equivalent of XML assembler.
> I didn't claim that AFs were perfect. They just point in the right
> direction. It is the responsibility of an AF processor to
> present a view
> of the data that is recognizable to the process (i.e. adheres
> strictly to
> the schema the process has agreed to). XML Schema did not
> define anything
> like that.
Okay. I'll look again at AF and see if I get the point. I'm not dense, just
stubborn.
|
