[xmlschemata] Re: Headaches w/ XDOTs

> From : Rick Jelliffe
> To : xmlschemata@xmlschemata.org
> Subject : [xmlschemata] Re: Headaches w/ XDOTs
>
> From: "Cyril Jandia" <cjandia@logfi.fr>
>
> > I guess (hope) this is now a little clearer :
> > http://xml-dot.org/#xdot-type-assignment-definition
>
> Yes, but it is still fuzzy :-)

> Would it be fair to say that you think that WXS does not go far
> enough in adopting OO techniques,

Yes... and nope, Rick:

Yes: WXS, IMHO, in some sense, went effectively (and I was pleased to hear
similar remarks from Eric on this, BTW) much too far in trying to
"object-orient" XML documents/data streams;
I mean, it made too much assumptions to build its meta-model nearly *from
scratch* -a martian would say- (is Meyer read, at W3C?), and I think it has
introduced *too many*, *non-orthogonal notions* - what is more, it *did* impose
a rather ad hoc way to implement all of them (arrghh... ;=)

More precisely:

(what struck me most) :

* Simple / complex data types

* Primitive types
* Derived data types

* Atomic types
* List types
* Union types

... and all the various cases where "you can do that, except but for..." (you
see ;=)

(I only find the datatypes' facets notions related to the lexical/value space
interesting, mainly)

So I could maybe put it like this :
for instance, why on earth limit us to lists/unions ?
Concretely, taking the risk to shock you, I'm pretty sure they are useful cases
where all of the following nodes (marked with "(*)") could be considered as
being *mere representation particles* of the very same, single, data type
instance :

...
<foobar foobar-att(*)="..."
  <gee(*)>...</gee>
  <gizmo
    <acme acme-att(*)="..." >...</acme>
    (*)....
  </gizmo>
</foobar>
...

Can we expect WXS to handle this ? Or even RNG w/ its datatype library-plug-in
capabilities?...

But also, nope: Meyer's object-orientation is *far* much simpler as well as more
*complete* and *consistent* :

1) client relation - direct and indirect (the latter, for closure of
dependencies between types and their usage of features);

2) inheritance relation - direct and indirect again; w/ support for multiple
inheritance (disciplined to avoid feature names' clashes)

3) then, he defined conformance between types : either class types or generic
class types - the latters being eventually, always instantiated (in the type
space) as "normal" class types (with actual generics mapped to formal
generics) - and it is now relatively well-known that Eiffel is much less tricky
than those C++'s template types, BTW;

Then, Eiffel's way of handling genericity w/ compound types is not limited to
those "list/union" ad hoc WXS's restrictions/extensions...

E.g, Eiffel's OO model allows to have the class type STRING to inherit from
ARRAY[CHARACTER].

4) finally, he defined clearly what polymorphism's supposed to be, as well as
feature redefinition (always explicit- see disciplined inheritance, in pt 3
above) with relating both to (2) and (3) *very* consistently;

5) IMO, remaining characteristics such as Eiffel's feature export policies
(equiv. to private/protected/public in other OOLs) are irrelevant, for now, for
XDOTs

> and with XDOT you want to explore a more pure approach? =20

Yep: that's exactly the point:
to be (as "pure" as possible) type-centric - well, I admit, from a particular,
arbitrarily chosen PoV: i.e, object-orientation.

> Which of Bertrand Meyer's ideas in particular do you think are
> promising here, if Eiffel is you inspiration?

(See above)

> Programming by contract in general?

Yes... and nope, Rick (bis ;=)

Yes : matter of fact, I think that equivalents to Meyer's assertions (pre-,
post-conditions, invariants - you know: all that DBC -Design By Contract-
stuff - by the way, a registered TM ;=)- *actually* are interesting to map to
local and/or global reference integrity, and co-occurrence issues we happen to
find w.r.t XML schema/typing languages;

But also, nope: these are *not* amongst the very first XML-DOT's priorities I'm
contemplating; neither is value defaulting (so I stay into your layered model,
you see, of "the State of the Art of Schema languages" ;=)

For me, the very first "new" issue to explore (i.e, my interest ;=) is this one:
OK : we now have an elegant way (conservative towards XML 1.0 DTD, but also,
evolutionary) to define content-models w/ namespace awareness - namely: RELAX
NG, at least - but...

... What on earth do we use content models, for? Does the way we use them to
depict structured data types instances w/in XML documents is actually adapted to
the various ways in which we can model our system at higher levels (e.g, UML) ?
I think that this question still is not clearly answered to, as of today, 2002 :
and I expect we could discover interesting things/properties in a near future to
automate this - safely, consistently, efficiently -provided we have a
well-designed tool (XML-DOT, why not? ;=)- for it...

> Cheers
> Rick Jelliffe

Best,
--CJ
Received on Fri Jul 5 15:47:39 2002