Sorry for the delay in reply. I think I'm very close to being in
agreement with you. I guess I'd summarize this exchange that "An XML
encoding of KIF would allow one to use a declarative scripting language
(included in the Windows operating system) for storage, presentation and
transformation, as a slight cost of more complicated syntax." Is that
close to how you'd summarize this? (01)
At 08:53 AM 11/22/2002 +0000, Martin Bryan wrote:
> > I appreciate the detailed and concrete response. While at some level I
> > agree with you, I feel that we may be approaching a religious
> > debate.
>Hopefully not. Too often religious debates lead to all out war :-(
> >Certainly, with a lisp reader one could have the same sort of
> > hierarchical data structure and lisp readers would tokenize the keywords
> > save space, so that's not unique to XML. But at that point, we're talking
> > about internal data structures, and not the interchange language. XML has
> > virtues because of it's current popular acceptance, but there are still
> > many issues that would need to be resolved.
>I'm not claiming it as a panacea, just as an approach that allows for
>declartive processing, which is something I happen to like.
> > Your element type approach does yield a more compact structure, but it
> > appears that you have lost the full expressivity of KIF in doing so. For
> > example, KIF allows a variable, terms, or function as an argument and your
> > proposal for the form
> > <instance id="variable-X">
> > <type>Horse</type>
> > </instance>
> > seems to assume that neither argument is a function application.
>I have not begun to attempt to fully model KIF. I simply tried to show that
>the example of XML given was unnecessarily verbose, as most examples I see
>from people who want to make the point that XML is verbose. I was trying to
>kill a chestnut that should never have been thrown on the fire.
> > I'm playing devil's advocate a bit here, but what's the compelling
> > benefit of this syntax change, even if you create an XML encoding
> > sufficient to handle the full expressivity of KIF?
>I'm always the devil's advocate, but the one pushing XML as the diabolical
> > The interchange
> > language becomes more verbose, and any tools that handle generic XML would
> > need to be specialized to handle not only the syntax of XML, but the
> > particular features of the encoding, and the semantics of KIF.
>No, that's my point. You don't need a specialized tool. You simply devise a
>set of declarative statements that allow a generalized XSLT tool to convert
>your XML representation of KIF to the required language. Yes, you can do
>that with any LISP compiler as well, but do you get that free with your
>operating system, in the way you get the XSLT tranlator?
> > So you've
> > just added another layer of software structure.
>You have to have another layer, whether its XML, LISP, Perl or Java. You
>need to be able to transform one strucuture into another. Its better to do
>this with a tool designed with such transformations in mind rather than with
>a general purpose tool.
>But I don't expect to convert you. Sometimes you have to let the heathens
>keep their own religions and simply use your own works as an examples to
>others of how they can improve their lives.
>Martin (The XML Devil's Advocate) Bryan
>To post messages mailto:ontolog@xxxxxxxxxxxxxxx
>An archive of the [ontolog] forum can be found
>at http://ontolog.cim3.org/forums/ontolog (03)
To post messages mailto:ontolog@xxxxxxxxxxxxxxx
An archive of the [ontolog] forum can be found
at http://ontolog.cim3.org/forums/ontolog (04)