Re: [unrev-II] XML limits

From: Paul Fernhout (
Date: Mon Apr 03 2000 - 18:38:40 PDT

  • Next message: Eric Armstrong: "Re: [unrev-II] Lifestreams"

    Eric Armstrong wrote:
    > Good note, Paul.


    > On the bright side, XML has standardized 3 important things that
    > needed standardizing:
    > * Encodings (ascii-based)
    > * Line Endings (newlines -- at least when they hit the program)
    > * Markup syntax


    > Despite its shortcomings, that base level of interchange-standardization
    > is *allowing* for standardized DTDs so that, one day, we can
    > actually get where we need to be.

    The point is there will never be standardized DTDs because needs keep
    Where we need to be keeps changing. You can't easily standardize
    knowledge representations because knowledge representation by itself
    requires flexibility in problem specific representation.

    That said, you can come up with common useful representations for common
    problems -- within limits. But whatever system you use should be able to
    move beyond common representations at a moment's notice as new
    problems/situations come up. The whole XML way of thinking (standardize
    a DTD everyone agrees on) goes against this flexilibity.

    > I'm interesting if *any* encoding system would solve the problems
    > you mention.

    No XML-ish scheme can. It's like saying the type of paper you use helpds
    you write a good novel. It may make a tiny difference if the paper is
    easier to put in the printer and doesn't curl as much in the humidity
    (i.e. XML line endings don't require conversion), but in general, the
    problem of writing a novel has little to do with the paper it is
    printwed on. So too the problems of knowledge representation have
    little to do with the character encoding, line endings, or markup

    > Possibly and object-based system, rather than a data- based system?

    Objects and such by themselves also don't solve the problem. In fact, to
    an extent object-oriented programming compounds the problem because it
    leads programmers down the garden path of thinking if they can just pick
    the right objects all will be simple.

    I wrote my undergraduate thesis "Why Intelligence: Object, Evolution,
    Stability, and Model" on what would now be called Evolutionary
    Psychology (done then as Cognitive Psychology). One major point was
    objects are an artificial construct that are useful for solving certain
    common survival problems simply and quickly. Every "object" one defines
    can under another circumstance require decomposition into subelements or
    require composition into another aggregate. Yet, objects are so
    prevalent in our way of thinking even cognitive psychologist take them
    for granted in conducting their research.

    Examples of things we can think about that transcend common object
    definitions and show the flexibility of human thought:
    * That apple is half eaten (where's the other half? -- in chunks in you,
    until it's digested and becomes part of you...)
    * Take apart the chair and glue it back together so it's less rickety.
    * What's inside a quark?

    The point is to create a DKR/OHS flexible enough to deal with this issue
    of representations changing over time as users needs change.

    The point is that XML hype doesn't even admit this problem exists and
    that it is the central one. In that sense, I see XML as just a
    distraction. Yes, it might be useful insome instances, but it is
    basically irrelevant as to addressing the core problems of knowledge

    And to take things further, why invent XML when one could instead just
    use LISP to the same effect (and with less bytes)? Lisp is used all the
    time to define representations such as:
      (ID 100001)
      (name "Grampa Muenster")
      (address "13 Mockingbird Lane"))
    Lisp can easily parse this which defines a valid LISP list, and we can
    define LISP programs with related data that validate such
    representations. That is what AI programmers have been doing for

    There isn't a good answer, other than to say that XML like Java is
    benefiting from hype and good marketing, and neither conceptually
    improve beyond where Lisp was a decade or two ago -- and both actually
    are a step backwards relative to Lisp because they both lack its
    generality and elegance.

    Lisp does have shortcomings and emotional baggage that a language like
    Smalltalk somewhat addresses (and in turn creates some of its own
    shortcomings). Java does have the initial advantage for C or Pascal
    programmers over Lisp or Smalltalk because the syntax looks more similar
    and makes it more approachable. XML seems to be easier to use for people
    who know SGML or HTML because it looks more familiar and people think
    that marking enging tags will be more reliable than counting parentheses
    (it doesn't matter when you use a structured editor or a editing tool
    like emacs). However, in my opinion, the investment in learning and
    using these other systems (Smalltalk, Lisp) is worth it.

    -Paul Fernhout
    Kurtz-Fernhout Software
    Developers of custom software and educational simulations
    Creators of the Garden with Insight(TM) garden simulator

    Get a NextCard Visa, in 30 seconds!
    1. Fill in the brief application
    2. Receive approval decision within 30 seconds
    3. Get rates as low as 2.9% Intro or 9.9% Fixed APR
    Apply NOW!

    Community email addresses:
      Post message:
      List owner:

    Shortcut URL to this page:

    This archive was generated by hypermail 2b29 : Mon Apr 03 2000 - 18:44:25 PDT