Thread: [exprla-devel] Re: The structure of classes in XPL
Status: Pre-Alpha
Brought to you by:
xpl2
Menu
▾
▴
exprla-devel
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:13:01
|
--- In xpl-dev@y..., "Garreth Galligan" <garreth.galligan@o...> wrote: Richard Anthony Hein wrote: >XPL doesn't need classes, but to make people comfortable we >can make them using XPointer This is fascinating, but I'm afraid I'm not too up to speed with XPointer. Do you know of any good reference material? W3C documentation is a slow, tedious read. >Subject: [XPL] requirements >3. XPL must be human readable. Agree with you absolutely, otherwise there would be no point in using a markup language for the job. Kurt Cagle wrote: >I think the idea of writing a general meta-language for >programming is ill-advised With you on this one; if I'm right about your meaning in 'general programming' as raised in some early posts which, more or less, envisage XPL as storage/transfer/interface/whatever medium for various existing languages. Great science, but a little too 'Star Trek' for me right now. However I'm still on the side of XPL as a 'meta-language' of sorts, for creating XPL based micro languages. >Let's concentrate on extending what already exists, >making XSLT more robust, Well with you in the spirit of the concept, which is to use applications of XPL for operation on other ML's. But it would take a lot of persuading to get me over my innate dislike of XSLT. It's such an *ugly* language, and is rooted in my mind as a tool for publishingMLs most likely to be produced in a WYSIWYG application. One needs to take a very deep breath before trying to hand code the stuff. I'm inclined to think of XSLT as a round hole to XPL's square peg, but then my experience with XSLT is hardly extensive and I'm open to persuasion... --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:59:39
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
Could a form of overloading address this problem? Like in a Java
class,
there may be multiple functions in the class that do different things
depending on the type of parameter (one may be a string, another may
be an
integer), but the overall function result is the same. So if you use
overloading, you call <human>, <mathematician>, and <programmer> as
if they
were different functions in the class?
Richard A. Hein
-----Original Message-----
From: Alexander E. Gutman [mailto:gutman@m...]
Sent: June 11, 2000 10:15 AM
To: xpl@e...
Subject: [XPL] The structure of classes in XPL
At this moment, I am thinking about how classes
will be declared in XPL. And I encountered a problem.
As soon as XPL is closely related to XML, the structure
of its classes should be as flexible as XML structures.
Should we regard classes as XML element types
(and, probably, declare them via schema element type definitions)
or should we employ a standard approach of some kind?
Consider me as an example of an XPL object.
First of all, I am a human.
As a human, I have a name (Alexander Gutman)
and birthdate (01.07.1966).
On the other hand, I am a mathematician.
As a mathematician, I have a name (Alex Goodman)
and workplace (Blahblah Institute).
Furthermore, I am also a programmer.
As a programmer, I have a name (Alex Softman)
and workplace (FoobarSoft).
In XML, the above information can be easily structured,
for instance, as follows:
<me>
<human>
<name>Alexander Gutman</name>
<birthdate>01.07.1966</birthdate>
</human>
<mathematician>
<name>Alex Goodman</name>
<workplace>Blahblah Institute</workplace>
</mathematician>
<programmer>
<name>Alex Softman</name>
<workplace>FoobarSoft</workplace>
</programmer>
</me>
The question is:
How such a structure can be modeled via "usual" classes?
Of course, there are many different solutions, but I wonder
if there is a solution close (in flexibility) to that of XML.
(You may use any concepts, including multiple inheritance.)
--
Alexander E. Gutman
----------------------------------------------------------------------
------
--
----------------------------------------------------------------------
------
--
To unsubscribe from this group, send an email to:
xpl-unsubscribe@o...
--- End forwarded message ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 08:59:54
|
--- In xpl-dev@y..., cagle@o... wrote:
There's a few differences I've encountered between object definitions
in XML and the same definitions in a language like Java that might
make overloading problematic. The first is that an XML Schema
definition is more like a VB type statement than a Java class -- 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. Keep in mind that the one primary
difference between XML and procedural objects is that the XML
instance of a schema may not necessarily be physically connected with
the methods that operate on it. We should thus ask whether XPL works
by keeping the XML instance data of a class as part of the object --
i.e., the XML acts as the local variables -- or the XML data arrives
as input and is processed in real time against the XPL/XSLT templates
(in which case the XPL objects are methods only). The former is a
statist approach -- the data needs to be retained between calls,
while the latter is stateless.
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. Note also that in the sample, you are
confusing data and structure. Rather than:
<me>
<human>
<name>Alexander Gutman</name>
<birthdate>01.07.1966</birthdate>
</human>
<mathematician>
<name>Alex Goodman</name>
<workplace>Blahblah Institute</workplace>
</mathematician>
<programmer>
<name>Alex Softman</name>
<workplace>FoobarSoft</workplace>
</programmer>
</me>
your structure could be changed to recognize that both mathematician
and programmer are both occupations:
<me>
<human>
<name>Alexander Gutman</name>
<birthdate>1996-07-01</birthdate>
<occupation>
<title>mathematician</title>
<workplace>BlahBlah Institute</workplace>
<alias>Alex Goodman</alias>
</occupation>
<occupation>
<title>programmer</title>
<workplace>Foobar Software</workplace>
<alias>Alex Softman</alias>
</occupation>
</human>
</me>
-- Kurt Cagle
----- Original Message -----
From: Richard Anthony Hein
To: xpl@e...
Sent: Sunday, June 11, 2000 10:51 AM
Subject: RE: [XPL] The structure of classes in XPL
Could a form of overloading address this problem? Like in a Java
class, there may be multiple functions in the class that do different
things depending on the type of parameter (one may be a string,
another may be an integer), but the overall function result is the
same. So if you use overloading, you call <human>, <mathematician>,
and <programmer> as if they were different functions in the class?
Richard A. Hein
-----Original Message-----
From: Alexander E. Gutman [mailto:gutman@m...]
Sent: June 11, 2000 10:15 AM
To: xpl@e...
Subject: [XPL] The structure of classes in XPL
At this moment, I am thinking about how classes
will be declared in XPL. And I encountered a problem.
As soon as XPL is closely related to XML, the structure
of its classes should be as flexible as XML structures.
Should we regard classes as XML element types
(and, probably, declare them via schema element type definitions)
or should we employ a standard approach of some kind?
Consider me as an example of an XPL object.
First of all, I am a human.
As a human, I have a name (Alexander Gutman)
and birthdate (01.07.1966).
On the other hand, I am a mathematician.
As a mathematician, I have a name (Alex Goodman)
and workplace (Blahblah Institute).
Furthermore, I am also a programmer.
As a programmer, I have a name (Alex Softman)
and workplace (FoobarSoft).
In XML, the above information can be easily structured,
for instance, as follows:
<me>
<human>
<name>Alexander Gutman</name>
<birthdate>01.07.1966</birthdate>
</human>
<mathematician>
<name>Alex Goodman</name>
<workplace>Blahblah Institute</workplace>
</mathematician>
<programmer>
<name>Alex Softman</name>
<workplace>FoobarSoft</workplace>
</programmer>
</me>
The question is:
How such a structure can be modeled via "usual" classes?
Of course, there are many different solutions, but I wonder
if there is a solution close (in flexibility) to that of XML.
(You may use any concepts, including multiple inheritance.)
--
Alexander E. Gutman
----------------------------------------------------------------------
------
----------------------------------------------------------------------
------
To unsubscribe from this group, send an email to:
xpl-unsubscribe@o...
----------------------------------------------------------------------
--------
----------------------------------------------------------------------
--------
To unsubscribe from this group, send an email to:
xpl-unsubscribe@o...
--- End forwarded message ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:00:28
|
--- 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 --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:00:53
|
--- In xpl-dev@y..., "Garreth Galligan" <garreth.galligan@o...> wrote:
When worlds collide, data architecture meets class architecture :)
What's good for data: highly ridged, hierarchical and dependent
structures
is not necessarily good for a program.
We are certainly staring right into the face of some very big and
interesting contradictions:
Alexander E. Gutman wrote:
> As soon as XPL is closely related to XML, the structure
> of its classes should be as flexible as XML structures.
> Should we regard classes as XML element types
> (and, probably, declare them via schema element type definitions)
> or should we employ a standard approach of some kind?
Just to muddy the waters further - Why Classes at all?
Do Classes truly have any relevance to XML?
Is XML and Classes a square peg in a round hole?
Are we forcing OO paradigms on XML for paradigms' sake?
I don't have the answers, just a lot of questions :)
> but I wonder if there is a solution close (in flexibility) to that
of XML
I risk my neck and offer classless (no pun intended) object-based
languages
(e.g. Self, JavaScript) as an alternative model which perhaps more
closely
mirror the flexibility and *simplicity* of XML. XML already offers
many of
the advantages of a class based system, e.g. encapsulation via
namespaces.
This is probably not the best example in the world to display
prototyping,
but:
<occupation id="occupation1">
<title>mathematician</title>
<workplace>An Institute</workplace>
<alias>Some Guy</alias>
</occupation>
<occupation id="occupation2">
<title>programmer</title>
<workplace>A Company</workplace>
<alias>Some Guy</alias>
</occupation>
<me>
<human>
<name>Alexander Gutman</name>
<birthdate>1996-07-01</birthdate>
</human>
<prototype obj="occupation1">
<workplace>BlahBlah Institute</workplace>
<alias>Alex Goodman</alias>
</prototype>
<prototype obj="occupation2">
<alias>Alex Softman</alias>
<workplace>Foobar Software</workplace>
<prototype>
<description>My main job</description>
</prototype>
</prototype>
</me>
As you can see with the above we are looking at a much simpler DTD in
terms
of structural relationships. Defining 'objects' on the simplest level
possible in the DTD and building up relationships in the instance
document.
--- End forwarded message ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:02:01
|
--- In xpl-dev@y..., cagle@o... wrote: I'm inclined to agree with you on the class issue. I've worried myself that the class paradigm provides a number of limitations to what is essentially a classless model. The problems with attempting to use an XML based code for a procedural language are unfortunately pretty major, but most boil down to Occam's razor -- is there any real benefit in coding a procedural language in XML that can't already be done with DOM? I'd contend that there really isn't -- most procedural languages work on one piece of a data document at a time, while XSL (as an example) tends to encourage a holistic approach to coding: find the relevent patterns in an XML document and apply the templates to the data. In this sense, the polymorphism that's done takes place at the abstract level of designing the XSL templates rather than at the object level. I suppose that you could work a registration scheme such that when an XML object with a recognized schema "entered the gate", so to speak, only those XSL filters that recognized the schema would be considered part of its methods, but again I think this falls into the square peg, round hole issue. I like to think that a better idea might be to associate with a document's schema a URN that pointed to another XML document that contained the interfaces and URLs of XSLT (XPL?) templates that could work on a given document (or perhaps in turn another pointer document, a la Gnutella). Such a registry document might also contain some kind of annotation element akin to that found in the XML Schema language, so that an IDE could retrieve a document, dereference its schema, dereference the templates document and then display the results as an intellisense like drop-box. I think this also opens up the possibility of polymorphism, declarative style -- there is no reason that two documents with distinct schemas couldn't reference the same set of templates (if the templates were general enough) nor why you couldn't create a schema that pointed to both a base set of templates and an augmented set for providing "subclassing" behavior. We need to determine whether or not we're writing a procedural or declarative language. I think the idea of writing a general meta- language for programming is ill-advised. Programming languages vary across the board from fairly simple scripted languages such as JavaScript to pointer driven languages such as C++ (I shudder to think of a C++ language implementation written in XML, to be honest) to text manipulation languages such as Perl. Moreover, I think that each of these languages does what it does quite well, and that it is far more difficult making from one linguistic namespace to the next. Let's concentrate on extending what already exists, making XSLT more robust, and developing an IDE that would work for such a solution. After that we can reprogram the world <grin/>. -- Kurt Cagle ----- Original Message ----- From: "Garreth Galligan" <garreth.galligan@o...> To: <xpl@e...> Sent: Monday, June 12, 2000 8:50 AM Subject: Re: [XPL] The structure of classes in XPL > When worlds collide, data architecture meets class architecture :) > What's good for data: highly ridged, hierarchical and dependent structures > is not necessarily good for a program. > > We are certainly staring right into the face of some very big and > interesting contradictions: > > > Alexander E. Gutman wrote: > > > As soon as XPL is closely related to XML, the structure > > of its classes should be as flexible as XML structures. > > Should we regard classes as XML element types > > (and, probably, declare them via schema element type definitions) > > or should we employ a standard approach of some kind? > > Just to muddy the waters further - Why Classes at all? > Do Classes truly have any relevance to XML? > Is XML and Classes a square peg in a round hole? > Are we forcing OO paradigms on XML for paradigms' sake? > I don't have the answers, just a lot of questions :) > > > but I wonder if there is a solution close (in flexibility) to that of XML > > I risk my neck and offer classless (no pun intended) object-based languages > (e.g. Self, JavaScript) as an alternative model which perhaps more closely > mirror the flexibility and *simplicity* of XML. XML already offers many of > the advantages of a class based system, e.g. encapsulation via namespaces. > > This is probably not the best example in the world to display prototyping, > but: > > <occupation id="occupation1"> > <title>mathematician</title> > <workplace>An Institute</workplace> > <alias>Some Guy</alias> > </occupation> > > <occupation id="occupation2"> > <title>programmer</title> > <workplace>A Company</workplace> > <alias>Some Guy</alias> > </occupation> > > > <me> > <human> > <name>Alexander Gutman</name> > <birthdate>1996-07-01</birthdate> > </human> > <prototype obj="occupation1"> > <workplace>BlahBlah Institute</workplace> > <alias>Alex Goodman</alias> > </prototype> > <prototype obj="occupation2"> > <alias>Alex Softman</alias> > <workplace>Foobar Software</workplace> > <prototype> > <description>My main job</description> > </prototype> > </prototype> > </me> > > As you can see with the above we are looking at a much simpler DTD in terms > of structural relationships. Defining 'objects' on the simplest level > possible in the DTD and building up relationships in the instance document. > > > -------------------------------------------------------------------- ---- > IT Professionals: Match your unique skills with the best IT projects at > http://click.egroups.com/1/3381/1/_/809694/_/960825006/ > -------------------------------------------------------------------- ---- > > To unsubscribe from this group, send an email to: > xpl-unsubscribe@o... > > > > --- End forwarded message --- |
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:02:18
|
--- In xpl-dev@y..., "Richard Anthony Hein" <935551@i...> wrote:
Ok, I am probably not the best person to try to supply a solution to
this,
but here's an idea I will throw out. XPL doesn't need classes, but
to make
people comfortable we can make them using XPointer. For example,
given a
class:
<cycle>
<wheels/>
<gears/>
...
</cycle>
we could reference this class in a sub-class like so:
<bicycle>
<xpl:inherits>
<xpl:inherit <!-- some XPointer reference to superclass
<cycle><wheels/> (I don't know how to do this) -->>
<!-- add your sub-class stuff here -->
<wheel>front</wheel> <!-- add children and whatever, even
point
to other classes -->
</xpl:inherit>
</xpl:inherit <!-- XPointer to superclass <cycle><gears> -->
<gear id="1">
<ratio>1:1</ratio>
...
</gear>
</xpl:inherit>
</xpl:inherits>
</bicycle>
Just a thought.
Richard A. Hein
-----Original Message-----
From: cagle@o... [mailto:cagle@o...]
Sent: June 12, 2000 10:07 PM
To: xpl@e...
Subject: Re: [XPL] The structure of classes in XPL
I'm inclined to agree with you on the class issue. I've worried
myself
that
the class paradigm provides a number of limitations to what is
essentially
a
classless model. The problems with attempting to use an XML based
code for
a
procedural language are unfortunately pretty major, but most boil
down to
Occam's razor -- is there any real benefit in coding a procedural
language
in XML that can't already be done with DOM? I'd contend that there
really
isn't -- most procedural languages work on one piece of a data
document
at
a time, while XSL (as an example) tends to encourage a holistic
approach
to
coding: find the relevent patterns in an XML document and apply the
templates to the data. In this sense, the polymorphism that's done
takes
place at the abstract level of designing the XSL templates rather
than at
the object level. I suppose that you could work a registration
scheme
such
that when an XML object with a recognized schema "entered the
gate", so to
speak, only those XSL filters that recognized the schema would be
considered
part of its methods, but again I think this falls into the square
peg,
round
hole issue.
I like to think that a better idea might be to associate with a
document's
schema a URN that pointed to another XML document that contained the
interfaces and URLs of XSLT (XPL?) templates that could work on a
given
document (or perhaps in turn another pointer document, a la
Gnutella).
Such
a registry document might also contain some kind of annotation
element
akin
to that found in the XML Schema language, so that an IDE could
retrieve a
document, dereference its schema, dereference the templates
document and
then display the results as an intellisense like drop-box.
I think this also opens up the possibility of polymorphism,
declarative
style -- there is no reason that two documents with distinct
schemas
couldn't reference the same set of templates (if the templates were
general
enough) nor why you couldn't create a schema that pointed to both a
base
set
of templates and an augmented set for providing "subclassing"
behavior.
We need to determine whether or not we're writing a procedural or
declarative language. I think the idea of writing a general meta-
language
for programming is ill-advised. Programming languages vary across
the
board
from fairly simple scripted languages such as JavaScript to pointer
driven
languages such as C++ (I shudder to think of a C++ language
implementation
written in XML, to be honest) to text manipulation languages such
as Perl.
Moreover, I think that each of these languages does what it does
quite
well,
and that it is far more difficult making from one linguistic
namespace to
the next. Let's concentrate on extending what already exists,
making XSLT
more robust, and developing an IDE that would work for such a
solution.
After that we can reprogram the world <grin/>.
-- Kurt Cagle
----- Original Message -----
From: "Garreth Galligan" <garreth.galligan@o...>
To: <xpl@e...>
Sent: Monday, June 12, 2000 8:50 AM
Subject: Re: [XPL] The structure of classes in XPL
> When worlds collide, data architecture meets class architecture :)
> What's good for data: highly ridged, hierarchical and dependent
structures
> is not necessarily good for a program.
>
> We are certainly staring right into the face of some very big and
> interesting contradictions:
>
>
> Alexander E. Gutman wrote:
>
> > As soon as XPL is closely related to XML, the structure
> > of its classes should be as flexible as XML structures.
> > Should we regard classes as XML element types
> > (and, probably, declare them via schema element type
definitions)
> > or should we employ a standard approach of some kind?
>
> Just to muddy the waters further - Why Classes at all?
> Do Classes truly have any relevance to XML?
> Is XML and Classes a square peg in a round hole?
> Are we forcing OO paradigms on XML for paradigms' sake?
> I don't have the answers, just a lot of questions :)
>
> > but I wonder if there is a solution close (in flexibility) to
that of
XML
>
> I risk my neck and offer classless (no pun intended) object-based
languages
> (e.g. Self, JavaScript) as an alternative model which perhaps more
closely
> mirror the flexibility and *simplicity* of XML. XML already
offers many
of
> the advantages of a class based system, e.g. encapsulation via
namespaces.
>
> This is probably not the best example in the world to display
prototyping,
> but:
>
> <occupation id="occupation1">
> <title>mathematician</title>
> <workplace>An Institute</workplace>
> <alias>Some Guy</alias>
> </occupation>
>
> <occupation id="occupation2">
> <title>programmer</title>
> <workplace>A Company</workplace>
> <alias>Some Guy</alias>
> </occupation>
>
>
> <me>
> <human>
> <name>Alexander Gutman</name>
> <birthdate>1996-07-01</birthdate>
> </human>
> <prototype obj="occupation1">
> <workplace>BlahBlah Institute</workplace>
> <alias>Alex Goodman</alias>
> </prototype>
> <prototype obj="occupation2">
> <alias>Alex Softman</alias>
> <workplace>Foobar Software</workplace>
> <prototype>
> <description>My main job</description>
> </prototype>
> </prototype>
> </me>
>
> As you can see with the above we are looking at a much simpler
DTD in
terms
> of structural relationships. Defining 'objects' on the simplest
level
> possible in the DTD and building up relationships in the instance
document.
>
>
> ------------------------------------------------------------------
------
> IT Professionals: Match your unique skills with the best IT
projects at
> http://click.egroups.com/1/3381/1/_/809694/_/960825006/
> ------------------------------------------------------------------
------
>
> To unsubscribe from this group, send an email to:
> xpl-unsubscribe@o...
>
>
>
>
----------------------------------------------------------------------
------
--
----------------------------------------------------------------------
------
--
To unsubscribe from this group, send an email to:
xpl-unsubscribe@o...
--- End forwarded message ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:02:58
|
--- In xpl-dev@y..., Jonathan Burns <saski@w...> wrote:
Some commentary on the thread so far:
Alexander Gutman (Sunday 11/06/00) leads off:
At this moment I am thinking about how classes
will be declared in XPL. And I encountered a problem.
AG (if I may) has a <me> element, with <human>,
<mathematician> and <programmer> elements nested within.
And he wants to know how this XPL classic would be
expressed as a class (or strictly, object) in standard
OOP languages.
The obvious way to start off, would be to define a class
for each of the inner elements, and then to define a class
<me>, whose objects contain one instance each of the three,
as private data.
So then the question is, how does he want class <me> to look
from the outside?
Again, the obvious way is to add methods to the <me>
interface: get_human, get_mathematician, get_programmer.
Each of these methods will return a copy of the private
instance of the element. What's nice is that methods
so named can return lists of the desired element; a null
list if the element isn't there in an instance of <me>,
or a list of several, if <me> is a programmer at two
different workplaces.
So it's obviously feasible. As a variation, one can
define class <occupation>, and subclass <mathematician>
and <programmer> from it. Then we could define method:
get_occupation, to return both kinds of element in a
list.
Richard Hein (11/06/00) replies:
So if you use overloading, you call <human>, [etc] as if
they were different functions in the class?
Answer: Yes. But there's no special need for overloading.
If what we want is to provide special interfaces for <me>,
then the interfaces of classes <human>, <mathematician>
etc are just what we want. OOP is working as advertised.
The "different functions" in the class will just be the
different methods, get_human etc, which extract the desired
instances from an instance of <me>.
Then Kurt Cagle comes in with the OTHER side of the question
(11/06/00):
[...] an XML Schema definition is
more like a VB type statement than a Java class -- 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.
The other side of the question is, can we implement some simple
methods using off-the-shelf XML tech?
Answers:
(1) A schema or a DTD for <me> will define the element types
and placement of its private data; e.g. can we have zero or
multiple private instances of <human>? But a schema or a DTD
will not provide us with methods for getting the private
elements out of <me> - or doing anything with them if we could.
(2) XPath will get the inner elements.
child::mathematician()
will do that job directly. And other facilities of XPath will
extract elements of much more complicated documents; and
count and compare and filter them besides. The limitation of
XPath is that all these operations are read-only - they only
ever copy data from a document. There is no provision for
binding additional methods to elements on extraction.
But it is worth noting, that if we are content with public
nested state data in our objects, the get_ methods are
built-in with XPath. To that extent, all XML documents with
some defining schema or DTD are objects already.
(3) XSLT will apply template operations to <me>, acting on
any pattern (i.e. XPath expression) which we provide in
an XSL Transform.
This is the means to provide class <me> with a proper
interface. But, it is not directly adapted to providing
the kind of interface with which we are familiar in OOP.
As far as I can make out, an XSL Transform defines one
method, together with its implementation.
The standard OOP interface consists of many methods,
with or without implementations.
This isn't much of a problem, as far as I can see.
We can certainly have a transform which calls a proxy
template - a stub, which can go on to call the real
method implementation. And we can define an XPL class
interface as a collection of transforms.
Kurt goes on to say:
Keep in mind that the one primary difference between XML and
procedural
objects is that the XML instance of a schema may not necessarily be
physically connected with the methods that operate on it.
We should thus ask whether XPL works by keeping the XML instance data
of a class as part of the object -- i.e., the XML acts as the local
variables --
or the XML data arrives as input and is processed in real time
against
the XPL/XSLT templates (in which case the XPL objects are methods
only).
The former is a statist approach -- the data needs to be retained
between calls, while the latter is stateless.
Well, I'm not necessarily against statist approaches. The data
has to be stored somewhere, after all - it's just a matter of
how far away we want to push the commitment to stored data.
But we will want to provide an indirection mechanism, where the
data for the pattern to be recognized in a transform is not
present in the object, but is assembled on the fly.
It looks as if such a mechanism has to be built into XPath,
though. For our purpose here, XPath needs to recognize:
<programmer ref=[URI] >
</programmer>
or some such.
I will say, that if we develop XPL as statelessly as possible,
we will wind up in the company of the extreme functional languages,
which have to admit constant data eventually; but by that time,
they have pushed it into an obscure corner of the syntax, which
nobody can quite remember. (E.g., you get a major realm tacked on,
of addresses trying to pretend they are get_ functions and
failing.) Such languages do produce some beautiful dataflow
plumbing, however.
Alexander replies (12/06/00):
Hmm... Could you clarify this idea?
Somewhat clarified, I hope.
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).
This raises the question, Is XSLT as powerful as we would like?
I'm undecided so far. XSLT provides quite the arsenal of tree-
building operations, and on first glance I can't gauge the
extent of the programming paradigms it supports.
Sometime soon, I'll give you at considerable length the benfits
of my experience with Mathematica, which is based on transformation
rules for tree-structured expressions. It looks very much like
XSLT to me. Mathematica demonstrates that you an do a LOT, just
by munging trees around.
Now my intuition is, when we want to bind "side-effects" to
XSLT, the way to do it is not to embed one dinky external-
language call in every production rule we recognize, but
rather to produce a complete document for whatever we want
an external system to perform. And we pass that document to
a special parser, which has the total API for the external
system bound into it. If we do it that way, then XSLT only
needs to transform trees for us.
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?
The way I've been describing, the XML object is indeed
the return value of the transform, I mean method.
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.
We probably wouldn't want to do it with a raw instance
of <me>. In fact I'd argue most strongly that at a deep
level we want it hardwired in that clients' parsers IGNORE
any references to executable stuff, except under very
specific conditions - e.g. their trusted browser detects
an <xpl:method> tag, and stops to verify that the XPL
document is from a trustworthy source.
However, the place we would actually like to put method
bindings is in XPL-enhanced schemas, which are XML
documents. The way I'm coming to see it, we would like
to provide a schema for each external API we address.
Oh! But didn't I say above that the place for our
methods was XSLT?
Not any more. Let XSLT munge trees.
But look, there's a major redundancy in XML technologies.
Everything which takes XML documents as input, does some
kind of traversal on the tree. Verifying parsers, XPath,
XSLT - they all do it. The fact is, they are all just
different flavours of Parser. They all recognize productions
in XML - that is, elements - as they wander up and down the
tree. They just take different actions at different points.
So there are various places in the XML accessory equipage,
where one might want to tack method hooks on. What we want
to do, is identify the best place to tack them, in order
to provide the standard OOP interface.
(1) Schema or DTD provides a map of the public interface.
(2) XPath, working on the schema, provides a general read-only
navigation interface, with actual get_ methods of many kinds.
(3) XSLT transforms, working on the elements returned by
XPath, provide the set_ methods which rearrange the tree,
and present the results as output.
(4) XSLT transforms also produce output trees (XML documents)
which define actions to be taken by external APIs.
(5) And special external-system parsers take those documents,
and traverse them so as to make the external-system calls
which implement the actions.
And NOW we have separation of interface from implementation.
Well, almost. Above, the schema maps the interface, inasfar
as the interface defines what kinds of elements are present.
It doesn't tell you want non-get_ methods are available.
The XSLTs in (4) and (5) do tell you what those methods are;
in fact so far, we're talking about on transform document
per method. But those transforms are the ones that actually
execute the methods, external side-effects aside.
So we probably do want a method-annotated Schema type for
XPL, which defines the available method interfaces by name
and parameter valence - but leaves the method actions to the
XSLTs.
Alexander has further questions on the OOP issue, but it seems
to me that the picture I'm drawing has a bearing on them all.
What do you think, AG?
Finally (so far), Garreth Galligan (12/06/00) puts the whole
OOP paradigm to the question.
<occupation id="occupation1">
<title>mathematician</title>
<workplace>An Institute</workplace>
<alias>Some Guy</alias>
</occupation>
<occupation id="occupation2">
<title>programmer</title>
<workplace>A Company</workplace>
<alias>Some Guy</alias>
</occupation>
<me>
<human>
<name>Alexander Gutman</name>
<birthdate>1996-07-01</birthdate>
</human>
<prototype obj="occupation1">
<workplace>BlahBlah Institute</workplace>
<alias>Alex Goodman</alias>
</prototype>
<prototype obj="occupation2">
<alias>Alex Softman</alias>
<workplace>Foobar Software</workplace>
<prototype>
<description>My main job</description>
</prototype>
</prototype>
</me>
What we have here is fairly close to the Mathematica style.
Aggregates, let's call them objects, are written out arbitrarily.
By default, they are available as prototypes.
When reused, an object brings in all the data with which it was
defined.
But any of that data may be overridden. Thus "occupation2" comes with
<title>, <workplace> and <alias> values as originally defined; but
the latter two get new overriding values. The whole <me> object
is available as a new prototype.
It's actually quite elegant - but there are things it can't tell me.
For instance, what if I now want to produce a second <me> instance,
for someone working two shifts as a mathematician. Do the default
rules state that the <programmer> element is copied to the new <me>,
or absent?
This kind of information - elements required, forbidden, unique,
many, etc - is easily included in a schema, once one has gone
to the trouble of building one.
With OOP - classes, schemas, interfaces, whatever - you get
control, for an effort upfront.
How did Mathematica make out, without it?
Not badly, for the most part. What you could do, with a bit of
manual work, was take any hand-made expression and substitute
variable names - named blanks - for chosen elements; the result
was then available as an expression pattern, which would match
the original and anything like it except for the values of
the blanked-out elements. And then, you made the pattern one
side of a rule, which produced a new expression from those
values.
When it came to Real OOP, there was a tendency to tie oneself
in knots. The problem was, if you had a complex structure,
you had to write horrible indexing expressions in quantity, to
abstract out the stuff you wanted to reuse.
I wouldn't rule out this bottom-up prototyping idea. If we can
hand-build this stuff, we can hand-convert it to schema form
with about the same effort.
All the best, cats
Jonathan
--- End forwarded message ---
|
|
From: reid_spencer <ras...@re...> - 2002-01-31 09:03:08
|
--- In xpl-dev@y..., cagle@o... wrote:
Jonathon,
Not wanting to reiterate your arguments (which are quite nice, by the
way) I would argue that an XSLT document is not necessarily one
transformation. Specifically, if you allow for named templates, then
the correlation between an XSLT document and a set of class methods
becomes somewhat stronger, especially if you utilize the <xsl:import>
command.
<xsl:stylesheet ...>
<xsl:import href="subfilters.xsl"/>
<xsl:param name="method_name"/>
<xsl:template match="/">
<xsl:call-template name="{$method_name}">
<xsl:with-param name="data" select="."/>
</xsl:call-template>
</xsl:template>
</xsl:stylesheet>
In this way, the parameter method_name effectively controls
which "method" is called. This is effectively your proxy stylesheet.
More tomorrow, when I'm a little more cogent ....
-- Kurt Cagle
--- End forwarded message ---
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X