"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);