[exprla-devel] Re: [XPL] The structure of classes in XPL

[reid_spencer <ras...@re...>]

--- In xpl-dev@y..., "Alexander E. Gutman" <gutman@m...> wrote:
Kurt Cagle wrote:

> the schema defines the type and positional characteristics
> of an XML structure, but not any associated methods or
> events. However, you could make a superclass structure that
> might actually include a schema and an associated stylesheet
> with named templates, with templates acting as methods.

Hmm... Could you clarify this idea?
As far as I know, the output of a transformation procedure
is always an XML document/object and, furthermore, we cannot
perform any actions during transformation other than those
which reflect the output (probably, the "eval" XSL element can
produce some side-effects during transformation, I do not know).
So, how can an XSL template act as a method?
It seems that the only thing such a method can do
is returning an XML object. Do you mean that this object
is the body of the method? Or its return value?

Actually, I thought about methods and discovered another
possibility of associating a method with an element type:
via an attribute whose name is that of the method
and default value the method's body (or its identifier).
However, I am not quite sure that this is a good idea.

> As to the question of object polymorphism, it would probably
> be a safe assumption to say that an object is something that
> has a base level schema definition. XML Schema has a
> polymorphism mechanism that may be applicable here -- you
> could create a virtual schema for a human, then create
> another schema that inherits off the human schema for an
> occupational schema.

In available XSL documentation, I cannot find any
advanced possibilities of inheriting a schema.
What do you mean by inheriting a schema?
Copying the ancestor schema with subsequent extension?

> Note also that in the sample, you are
> confusing data and structure. Rather than:
[...]
> your structure could be changed to recognize that both
> mathematician and programmer are both occupations:
[...]

Of course, your structure is much better than mine.
However, my example was just an illustration of how
an XML structure can reflect the idea of multiple
class membership -- such an extremal polymorphism,
when an object can belong to several classes simultaneously
which are not connected via inheritance relations.
In your example, the object does not belong to several
classes, just to a single class, "human".

I am still thinking about XPL classes.
Suppose, they are XML element types.
(By the way, I do not suggest that all classes should
be element types. Probably, some of them could be so.)
Is it worth considering ANY element type as an XPL class?
Or should an element type meet some additional
requirements to be considered as an XPL class?
Is it worth exploiting XPath language in methods
or should the entire code be expressed via pure XML?
If any XML element type can be an XPL class,
what is the interface of such a class?
What does the language of methods' bodies look like?
What operators should it include?
Do we reinvent the DOM interface in this case?
Is it bad if we do so?

--
Alexander E. Gutman
--- End forwarded message ---