[
Lists Home |
Date Index |
Thread Index
]
> The specific argument is that XML Schema should not allow
> derivation by
> extension by default. And people should be very careful if
> they choose to
> do it explicitly.
I can agree with that. It should at least be a configurable option in any
XML Schema editor.
> The general argument is that this kind of confusion arises because XML
> Schema is trying to do two jobs at once. First it is trying
> to constrain
> the *syntax* of a class of XML documents. In this it is like
> DTDs, RELAX,
> etc. The second thing is to try to define a mapping into an object
> oriented model with subtyping. In this it is unique. As they
> say: "It is
> both good and original. But that which is good is not
> original and that
> which is original is not good." ;)
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. OOP goes one step further and associates
properties and methods with a concept, but halving that representation seems
perfectly reasonable, and in fact can be done using methodless structs in
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.
>
> Mapping from XML into objects is fine. But it is a totally
> separate and
> unrelated task to *defining the schema* for the XML.
It can be separable, just as Objects can be separated into data definitions
+ methods. There's a lot of freedom in keeping methods loosely bound to
data structures.
> 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.
> One job is defining syntax. A
> separate job is defining semantics/ontology (whether using OO
> techniques,
> logic techniques, whatever).
If XML was just a serialization of the data of one particular object model,
I would agree with that. But XML may represent data of a type that is
manifested diffently in different object models. So it becomes a mapping of
one semantic into another, related semantic.
>
> I took a stab at solving the object-binding problem myself.
> I'm not sure
> whether to continue with it as is because I'm very tempted by a
> Regular-language based strategy:
>
> http://www.prescod.net/xml/xbind/
>
> I haven't had as much time for it as I would like.
I've had similar thoughts, posted on this list previously. Why would you
prefer to go to the Dark Side, instead? :-)
>
> If I were going to build subtyping into a schema language, it
> would be in
> some sense transformation based. The gist of it is that it is the new
> types responsibility to describe how it can be mapped into an
> instance of
> the supertype. And it would be the responsibility of some bit
> of software
> (schema processor, PSVI generator, something) to hide the
> extra stuff from
> applications who don't want to see it.
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.
> There are too many details to go into but the gist is that
> archforms are
> ackward but they have the right ideas, IMO.
Ah, so your backspace key is worn through, then...
|
