Abstract: "Every text realizes a communicative act, but most contemporary text encoding ignores this. Betraying its unwitting subjection to a persuasive formalist ideology, current descriptive markup offers a static, document-oriented view of texts that occludes their temporal and performative nature."

A semi-serious note written in MLTP's Squibical genre reminding authors that no style manual whatever authorizes the use of the apostrophe as a generalized orthographic tool for constructing plurals in the English language. The note offers several theories to explain why authors sometimes write DTD's for the plural absolute instead of DTDs. The form DTD's would have to be singular possessive or a contraction for "DTD is." Some people fear that the gratuitous use apostrophe will bring civilization to a cataclysmic end through "Apostrolypse" (alternately, "Apostroluge"), as explained in the online note "Infrequently Asked Questions Concerning the Proper Spelling of 'DTD' in its Plural Form."

Abstract: "The present study discusses the advantages and disadvantages of general vs specific DTDs at different stages in the life of an SGML document based on the example of support for textual critical editions in the TEI. These issues are related to the question of when to use elements, attribute, or data content to represent information in SGML and XML documents, and the article identifies several ways in which these decisions control both the degree of structural control and validation during authoring and the generality of the DTDs. It then offers three strategies for reconciling the need for general DTDs for some purposes and specific DTDs for others. All three strategies require no non-SGML structural validation and ultimately produce fully TEI-conformant output. The issues under consideration are relevant not only for the preparation of textual critical editions, but also for other element-vs-attribute decisions and general design issues pertaining to broad and flexible DTDs, such as those employed by the TEI."

Results of a survey asking "What do you see in the future for Standard Generalized Markup Language?"

Abstract: "This paper explores three questions that are of interest to software companies developing XML editors. First, do we need XML editors? It can be argued that a spreadsheet tool like Microsoft Excel will be an XML editor when it saves data in XML. The corollary of this argument is that the current crop of commercially available XML editors -- for example, Adept, XMetaL, and Documentor -- will be spreadsheet tools when they can read Excel files. Such arguments are not sensible and quickly lead to the conclusion that when XML becomes the standard storage format it will no longer be useful to talk about XML editors. The next generationof XML editors will be clients! Second, does standardization limit development of XML clients or is it a driving force? If XML clients are compelled to handle paragraphs, tables, and equations (and only these), and if styling is limited to CSS and XSL, how will different client manufacturers compete? Will there be any incentive for creativity and innovation? Vendor-specific styling is a prerequisite for market-driven development of XML clients. Third, should XML clients be free? No, customers will pay for services and they don't care whether those services are performed by a client or a server. In fact, they cannot tell."

QDA (Quantum Document Architecture) is an application of the concepts of SGML to the problem of document flexibility and reuse.

Abstract: "This article describes the work of the OASIS Technical Committee on XSLT/XPath Conformance Testing. It examines the verbiage of two W3C (World Wide Web Consortium) Recommendations and describes some complexities that arise in interpretation. The deliberate grants of developer discretion are acknowledged, and the impact on testing is discussed. Expectations for contributed test cases are given."

Selection from an ongoing research project to identify the true roots and genealogy of ISO 8879:1986 (Standard Generalized Markup Language).

Abstract: "The contract can be represented by a property set (ISO 10744) that is historically grounded, results- rather than process-oriented, and meets requirements for equity, portability, and verifiability for all notation processors (sentient or not). A set of architectural forms is presented that conforms to the property set."

Because the contract is ubiquitous in commercial life (and thus in life), applications for a contract property set are almost too numerous to be worth mentioning. Therefore, I will simply list a few here: (1) On-line, ready-to-use, boilerplate contracts; (2) Specification for conversion operations; (3) Lending equity to XSL transforms; (4) Electronic commerce; (5) Enterprise modeling; and (6) Semantic overlays to legacy procedural code. These applications may well require different architectures conforming to the contract property set.

Abstract: "Many document query languages are currently proposed for specifying document retrieval. But the formalisms for document query languages are still underdeveloped. An adequate formalism is critical for query language development and standardization. Classical formalisms, relational algebra and relational calculus, are used to evaluate the expressive power and completeness of relational query languages. Most relational query languages embed within them either one or a combination of these classical formalisms. However, these formalisms cannot be directly used for tree document query languages due to different underlying data models. In this paper, we propose a logic formalism, called path predicate calculus, based on a tree document model and paths for querying XML. In the path predicate calculus, the atomic logic formulas are element predicates rather than relation predicates as in relational calculus. In this path predicate calculus, queries are equivalent to finding all proofs of the existential closure of logical assertions in the form of path predicates that document elements must satisfy."

Abstract: "The Standard Generalized Markup Language (SGML) and the Extensible Markup Language (XML) allow authors to better transmit the semantics in their documents by explicitly specifying the relevant structures in a document or class of documents by means of document type definitions (DTDs). Several authors have proposed to regard DTDs as extended context-free grammars expressed in a notation similar to extended Backus-Naur form. In addition, the SGML standard allows the semantics of content models (the right-hand side of productions) to be modified by exceptions. Inclusion exceptions allow named elements to appear anywhere within the content of a content model, and exclusion exceptions preclude named elements from appearing in the content of a content model. Since XML does not allow exceptions, the problem of exception removal has received much interest recently. Motivated by this, Kilpeläinen and Wood have proved that exceptions do not increase the expressive power of extended context-free grammars and that for each DTD with exceptions, we can obtain a structurally equivalent extended context-free grammar. Since their argument was based on an exponential simulation, they also conjectured that an exponential blow-up in the size of the grammar is a necessary devil when purging exceptions away. We prove their conjecture under the most realistic assumption that NP-complete problems do not admit non-uniform polynomial-time algorithms. Kilpeläinen and Wood also asked whether the parsing problem for extended context-free grammars with exceptions admits efficient algorithmic solution. We show the NP-completeness of the very basic problem: given a string w and a context-free grammar G (not even extended) with exclusion exceptions (no inclusion exceptions needed), decide whether w belongs to the language generated by G . Our results and arguments point up the limitations of using extended context-free grammars as a model of SGML, especially when one is interested in understanding issues related to exceptions."

Final remarks: "The role of XML is to allow documents to be served, received, and processed on the Web. Even though it is now clear that context-free grammars with exceptions have their limits in modeling SGML, the ideas in the proof of Theorem 3 [above] can possibly help in understanding which aspects or ingredients of the exception mechanism should definitely not be included, for efficiency reasons, into the XML standard. Or, at least, we do not know of other formal steps or partial results on this front. Indeed, the use of exceptions begins to appear controversial even for authors, in that, although exceptions are useful and even handy at first, they add significantly to the complexity of authoring DTDs as their size and complexity grows. Even if this phenomenon had been sometimes denied, or attributed to poor style in the use of exceptions, it is shown in [Matzen 1999], on the basis of an empirical analysis, that the complexity of some DTDs is approaching (or has exceeded) manageable limits given existing tools for designing and understanding them, and it is nowadays commonly believed that only partial solutions to this problem can be attempted; see Matzen 1999, Matzen/Hedrick 1998, and Matzen/Hendrick 1997. Our results now provide a formal justification of the occurrence of these problems which are known to imply high costs for DTD design and corresponding problems with quality."

"Steve Muench has written a very useful book for developers who need to understand how to work with XML and an Oracle database. Oracle provides several XML tools, and the book goes into them in some detail (including lots of examples). This is not a book about the pros and cons of using relational databases to store XML; it is, however, a book that developers who work with XML in the context of a relational database will often turn to, at least when they are starting to put it all together. XML is not just the 30-page specification it started out to be; the family of XML-related specifications has been extended to include specifications for transformation, for disambiguating element type names, and for a standard API to the various objects that make up an XML document or datum. Oracle has software tools that implement several XML-related specifications, and these tools are discussed in the book. Oracle has also defined its own XML-related technologies, such as XSQL, which are given equally detailed treatment. Java is the progamming language most heavily used for the examples (along with PL/SQL, Oracle's proprietary language)... I would strongly recommend that developers who use Oracle's XML-related tools have a copy of this book to hand. Developers working with other relational databases would probably also benefit from having some access.