"a data interchange format should be easy to read and understand with a simple editor
 by trained people"
   opposition: "a data interchange format is for data exchange between machines and
                hence does not have to be read directly by people" (pm),
   specialization: "a knowledge interchange format should be easy to read and 
                    understand with a simple editor, by trained people" (pm),
   argument: "any argument for using XML or any other textual notation 
              rather than a binary format" (pm),
   objection: "any argument for using a binary format rather than XML or any other
               textual notation" (pm);


   "a knowledge interchange format should be easy to read and understand with
    a simple editor, by trained people"
      argument: ("it may be cumbersome or inadequate to have to call 
                  translators/viewers/editors from some programs"
                    argument: ("having to use translators/viewers/editors when writing or
                                reading emails is cumbersome or impossible"
                                  argument: "this is obviously true when reading/writing
                                             emails through a text-only interface (telnet,
                                             ssh, putty, simple mailers, etc.)" (pm)
                              )(pm)
                )(pm),
      argument: "developing/debugging translators/viewers/editors for a knowledge 
                 interchange format is much easier if the format is easy to read" (pm),
      argument: "documents about the translation from/to the knowledge interchange format 
                 are easier to write if the format is easy to write" (pm),
      argument: "flexible translators/viewers/editors are difficult to program" (pm),
      argument: "a translator/viewer/editor good enough for all users, kinds of knowledge
                 or purposes may not be available or freely available" (pm),
      argument: ("a good notation and a good text editor are often more convenient to use
                  than XML/graphic/... editors"
                    objection: ("no linear (textual) representation can scale up"
                                   opposition: "for people's understanding purposes, only 
                                                a concise linear (textual) notation may
                                                scale up" (pm)
                               )(fg),
                    objection: "textual representations are mastered only by developers
                                 or other technical people" (fg,
                      objection: "graphic-based representation are not better 'mastered' by
                                  non-technical people than textual representations" (pm),
                      objection: "textual representations does not prevent the use of
                                  tools (structured editors, graphic viewers, etc.) but
                                  XML-based/graphical-based representations force the
                                  use of additional tools" (pm))
                )(pm),
      argument: ("for various reasons (e.g. to avoid the numerous issues related
                  to translations), people have/tend to write directly in the
                  knowledge interchange format"
                    argument_by_authority: "the authors of KIF regret not to have 
                                            understood this earlier and come up with
                                            a more intuitive notation" (pm)
                )(pm);



"for people's understanding purposes, only a concise linear (textual),
 notation may scale up"
   argument: ("graphic notations are not concise enough to be scalable
               for people's understanding purposes"
                 example: "natural languages are not graphic" (pm),
                 example: "most programming languages are not graphic" (pm),
                 example: "flow charts have been abandonned in favor of pseudcode
                           because they were far less practical/scalable" (pm),
                 argument: "scalability for people's understanding purposes requires
                            as much information as possible to be seen without having
                            to scroll or browse" (pm)
             )(pm);


"scalability for people's understanding purposes requires as much information as
 possible to be seen without having to scroll or browse"
   argument: - "scalability for people's understanding purposes requires many quick
                comparisons of information" (pm)
             - ("synthesis/comparison of information not accessible at a glance is
                 tedious and limited"
                   example: "having to browse through a translation dictionary to 
                             understand the words of sentences in a foreign language
                             make the sentences much harder to understand than if
                             the translation of each word or sentence is given after
                             each word or sentence" (pm)
               )(pm);

"a KRL (Knowledge Representation Language) can have an XML notation"
   extended_specialization: "a KRL should have an XML notation" (pm),
   argument: ("the data model of a KRL can be stored into a tree-based structure"
                 argument: - "a graph-based model can be stored into a tree-based
                              structure" (pm)
                           - "the data model of a KRL has to be graph-based" (pm)
             )(pm);


   "a KRL should (also) have an XML notation"
      specialization: "the Semantic Web KRL should have an XML notation" (pm),
      argument: "an XML notation permits a KRL to use URIs and Unicode" (fg,
        objection: ("most syntaxes can easily be adapted to have
                     object identifiers using URIs and Unicode"
                       argument_by_authority: "this was noted by Berners-Lee" (pm)
                   )(pm)),
      argument: "XML can be used for knowledge exchange or storage" (fg,
        objection: "XML is useless or detrimental for knowledge representation, exchange
                    or storage" (pm)),
      argument: "a KRL may have various notations in addition to an 
                 XML-based notation" (pm,
        objection: "the more notations there are the less one of them is going to be
                    commonly adopted for knowledge exchange" (pm)),
      argument: "not using XML for a notation implies that a plug-in has to be installed
                 for each syntax" (pm,
        objection: "XML tools need to be complemented for the semantics of
                    the knowledge representation to be handled" (pm),
        objection: "installing a plug-in is likely to take less time than 
                    always loading XML files" (sowa));



"the data model of a KRL has to be graph-based"
   argument_by_popularity: "this is acknowledged by about everyone" (pm),
   argument_by_authority: "this is acknowledged by the W3C" (pm);


"XML can be used for knowledge exchange or storage"
   argument: - "an XML notation permits classic XML tools (parsers, XSLT, ...) to
                be re-used" (pm)
             - "classic XML tools are usable even if a graph-based model
                is used" (pm);


"classic XML tools are usable even if a graph-based model is used"
   specialization: "classic XML tools work on RDF/XML" (pm);




"XML is useless or detrimental for knowledge representation, exchange or storage"
   argument: ("using XML tools for KBSs is a useless additional task"
                 argument: "KBSs do not use XML internally" (pm,
                   objection: "XML can be used for knowledge exchange or storage" (fg,
                     objection: "it is as easy to use other formats for
                                 knowledge exchange or storage" (pm),
                     objection: "a KBS (also) have to use other formats for
                                 knowledge exchange or storage" (pm)))
             )(pm),
   argument: "XML is not a good format for knowledge exchange or storage" (pm);


"XML is not a good format for knowledge exchange or storage"
   argument: - ("XML-based knowledge representations are hard to understand"
                   argument_by_popularity: "this is acknowledged by about everyone" (pm),
                   argument_by_authority: "this is acknowledged by the W3C" (pm)
               )(pm)
             - "a knowledge interchange format should be easy to read and understand
                with a simple editor, by trained people" (pm);

"the Semantic Web KRL should have an XML notation"
   specialization: "the Semantic Web KRL should have an XML syntax but a
                    graph-based model" (pm);


   "the Semantic Web KRL should have an XML syntax but a graph-based model"
      specialization: "RDF should have the current RDF/XML syntax",
      argument: ("this is for flexibility and normalization reasons"
                    argument_by_authority: "this was noted by Berners-Lee" (pm))(pm),
      argument: "classic XML tools re-usable even if a graph-based model is used" (pm),
      negative_consequence: "XML and RDF/XML are partially redundant standards" (pm),
      objection: ("a subset of XML can be used for representing knowledge"
                     example: "EARL, MPV, RSS" (pm))(pm);


      "RDF should have the current RDF/XML syntax and model"
         objection: "the current RDF/XML syntax is arbitrary and hard to understand" (pm),
         objection: ("the current RDF/XML syntax leads the user to make 
                      knowledge representation errors"
                        argument: "the current RDF/XML syntax does not support
                                   schema validation languages" (pm,
                          objection: "OWL provides schema validation constructs" (fg,
                            objection: "for expressive knowledge, RDF/XML+OWL (even
                                        OWL-full), often leads to ad-hoc/biased/un-reusable
                                        representations" (pm)))
                    )(pm),
         objection: ("the current RDF/XML model is inefficient compared to an XML one"
                       argument: "RDF/XML parsers are 5-20 times slower than XML parsers" (pm)
                    )(pm);


"classic XML tools work on RDF/XML"
   corrective_restriction: "classic XML tools can exploit the tree structure of
                            RDF/XML but ignore its added semantics" (pm,
                               example: "classic XML tools do not take into
                                         account the fact that RDF/XML has
                                         multiple equivalent serialisations" (pm));



"for expressive knowledge, RDF/XML+OWL (even OWL-full) often leads to 
 ad-hoc/biaised/un-reusable representations"
   argument: "many common aspects regarding sets and meta-statements can only be
             represented in an ad-hoc way" (pm),
   argument: "OWL is a low level language ontology and hence permits things to be
             represented in many more incomparable ways than when higher levels
             languages are used" (pm),
   example: "see http://www.webkb.org/doc/model/comparisons.html" (pm);