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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

--- 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 ---