"The Perseus Project developed a generalized toolset to manage XML documents in the context of a large, heterogeneous digital library. The system manages multiple DTDs through mappings from elements in the DTD to abstract document structures. The abstraction of document metadata, both structural and descriptive, facilitates the development of application-level tools for knowledge management and document presentation. Implementation of the XML back end is discussed and applications described for cross citation retrieval, toponym extraction and plotting, automatic hypertext generation, morphology, and word co-occurrence... One of the greatest challenges in building and maintaining a large, heterogeneous DL (digital library) is the necessity of managing documents with widely varying encodings and markup practices. Although the World Wide Web has demonstrated the power of simple links among simple documents, the benefits of more highly structured markup have long been understood. The Perseus digital library project has developed a generalizable toolset to manage XML (Extensible Markup Language) documents of varying DTDs (Document Type Definitions); to extract structural and descriptive metadata from these documents and deliver document fragments on demand; and to support other tools that analyze linguistic and conceptual features and manage document layout. In over ten years of creating and managing SGML and now XML data, we have been greatly helped by the generality and abstraction of structured markup, which has allowed us to deliver our content smoothly on a variety of platforms, from standalone CDROMs, to custom client/server software, to the World Wide Web. In digitizing historical and scholarly documents, we have also come to appreciate the richness of the implicit and explicit links among printed resources. Our DL system reifies these connections and tries to meet the challenges of automatically generating hypertexts in electronic media. Most often needed in creating a rich hypertext across a digital library are models of the structure of individual documents and descriptions of their content. These models ought to be independent of the particular encodings of those documents. Use of these abstractions allows rapid development of scalable tools for display, linguistic analysis, knowledge management, and information retrieval within the DL system. We describe an engine to leverage the power of XML for this modeling task and some of its applications in building a hypertextual digital library. This document management system is the back end for a production web server that delivers over 2 million pages a week; it went into production early in March, 2000... We have described an XML document management system for a digital library. This system facilitates development of knowledge management applications including those for display, feature extraction, and automatic hypertext generation. Our DL system facilitates development of these and other applications because it releases the application programmer from the task of indexing collections of documents written in multiple DTDs. Because the modules scale as the DL grows, documents in the integrated DL become more valuable than those existing in isolation."

"SGML and XML markup allows the user to make (licenses) certain inferences about passages in the marked-up material; in particular, markup signals the occurrence of specific features in a document. Some features are distributed, and their occurrences are logically non-countable (italic font is a simple example); others are non-distributed (paragraphs and other standard textual structures, for example). Formally, the inferences licensed by markup may be expressed as open sentences, whose blanks are to be filled by the contents of an element, by an attribute value, by an individual token of an attribute value, etc. The task of interpreting the meaning of the markup at a particular location in a document may then be formulated as finding the set of inferences about that location which may be drawn on the basis of the markup in the document. Several different approaches to this problem are outlined; one measure of their relative complexity is the complexity of the expressions which are allowed to fill the slots in the open sentences which formally specify the meaning of a markup language... If markup has meaning, it seems fair to ask how to identify the meaning of the markup used in a document, and how to document the meaning assigned to particular markup constructs by specifications of markup languages (e.g., by DTDs and their documentation). In this paper, we propose an account of how markup licenses inferences, and how to tell, for a given marked up text, what inferences are actually licensed by its markup. We illustrate this account using a simple representation of markup and markup meaning in Prolog. As a side effect of this account of how to interpret markup, we will also provide: (1) an account of what is needed in a specification of the meaning of a markup language, (2) a way to determine, for a markup construct in a document, what inferences it licenses, and conversely (3) a way to determine, for any part of a text, what inferences about it are licensed by the markup. The work described here may thus lead to improved documentation for markup languages; by providing a more formal approach to markup meaning it may make possible a survey of current practice which would be of interest to software developers. A deeper understanding of how to interpret markup should make it easier to normalize markup so as to reduce the variety of ways in which the same information is conveyed within a given body of material, or to improve the performance of query tools. Some applications to problems of semantic verification are also possible. We begin by describing a simple method of expressing the meaning of SGML or XML element types and attributes; we then identify several ways in which this simple method fails to work in practice. From these failures, we can infer a fundamental distinction between distributive and non-distributive features of texts, which affects the interpretation of markup, as well as some other properties of markup important for its interpretation. We then outline a revised proposal, which is incomplete but which provides a suitable framework for further elaboration; the last section briefly lists some things which must clearly be added to the framework in order to enable the description of existing widely known markup languages..."

"Navigation and links can be made easier for an author to manage when they are collected into separate relationship documents, or navigation maps, which use the same semantics for describing relationships as are used to structure content models in other documents in their domain. By reusing content structuring semantics for relationship management, the relationships captured in a relationship document can be accessed and manipulated through the document's document object model (DOM). By layering multiple relationship documents with different structuring paradigms, an author can create and manage a multidimensional web, and avoid display issues or comprehension problems associated with handling that complexity in a single document. This paper describes a prototype project that exercised these principles against a simple web... While this process is probably not suitable for webs containing more than a few thousand documents, or for webs with various or unorganized content, it is highly suitable for relatively cohesive, self-contained webs, such as the user support webs for a single product. For authoring help webs and similar constrained collections, this approach reduced the complexity of relationship management to a simple, useful, and intuitive process that melded well with the existing web authoring process. While the prototype dealt with simple HTML documents, the process would work equally well with more variegated XML content. Adding further semantics and structures to the document domain, and by implication to the relationship document, would simply introduce additional, or different, types and roles. Because the relationships are expressed in terms of DOMs (the DOM for each navigation map), constraints on allowable relationships should be relatively easy to express using a DTD. For example, the DTD could enforce a maximum nesting level (as this conference paper format does for subheadings). This is certainly not a one-size-fits-all solution. However, it works well in at least one case, and has comparatively low entry costs in terms of learning curve and technological requirements, since it uses standard HTML structures. This should make it a useful starting point for some well-architected web sites."

"XML messaging between software agents provides a powerful and flexible infrastructure, which facilitates the design of systems in which transactions involve multiple users and data stores. We describe the AiT enTReX border management system, which implements this architecture. This system integrates varied data types and sources (such as traveler's documents, video surveillance images, messages, and multiple national databases) in the context of varying national languages, it resources, interface hardware requirements, and workflows. Functional modules of the architecture are encapsulated in software agents which handle client interface, system policy and database interface and which intercommunicate using XML and Internet protocols. XML provides key advantages in this architecture: (1) a flexible, presentation-independent message format between software components, (2) a database neutral data format, and (3) the option of using XSLT, a flexible transformation and formatting technology. The separation of functionality imposed by the use of XML messages and software agents facilitates efficient customization for customer requirements in presentation, database interface, and system workflow. Introduction xml messaging between software agents is a powerful and flexible infrastructure for transactions involving complex workflow involving multiple users. This paper describes AiT's enTReX border management system, which is an implementation of this architecture to solve the policy issues of border management in a way that is easily customizable for specific client requirements. The structure of the architecture and function of the components is discussed, as well as the design of the messaging semantics. While specifically designed for border management, this architecture is sufficiently flexible to be applicable to systems where access to diverse information stores, complicated and tightly regulated workflow, rigorous security, and access controls are important... The system architecture is based on a set of software agents (long-lasting, semi-autonomous, interacting software components) which intercommunicate using XML messaging. Each agent specializes in providing a particular set of functionality. The agents are autonomous in that information and how it is processed is encapsulated from the rest of the system. This approach provides a clean separation of responsibilities and partitioning of the system. Within each agent, event information is encapsulated using an object component model. Each agent does one thing well. The system is partitioned into functional units which are assigned to agents. For example, the PE simply emits structured messages without regard to presentation. All presentation functionality is handled at the client interface agent level. These agents are then able to handle the details of output to the specific medium. This paradigm works very naturally with XML message content, and with the use of xslt for presentation transformations. Similarly, the DB interface agents handle all database specific details. For DB interface to rdmbs data stores, XML messages are transformed into SQL commands using XSLT... Frequently, client server architectures built initially to one country's, and subsequently modified for another's, specifications will tend to have code for workflow, user interface, and database interface mixed throughout the application. This can quickly lead to a 'customization nightmare' in which the bugs caught in one implementation go uncorrected in others. This architecture attempts to solve this problem by cleanly separating the the structural pieces of the system into the various agents. XML facilitates this process by allowing a clean separation of data content and presentation. This allows the policy engine to emit generic XML packets which are adapted by: (1) the client interface agents for display to clients on various devices, such as browsers, and pagers; and (2) the database interface agents to communicate with a wide variety of modern and legacy databases. One significant advantage of the central policy engine used in this architecture is the capability for multi-client cooperation. Unlike many client-server architectures, where each client has an essentially private session with the server, border management may require, for example, information in a primary agent's session to be viewed by a supervisor for a decision. While this architecture has been presented in the context of border control, we feel that its capabilities and strengths are applicable in a wide variety contexts. Many large business, government, and health care systems require multi-client interaction, rigorous control of workflow and policy, and the ability to draw information from various data sources. We feel autonomous agents with XML messaging provides flexible and powerful infrastructure upon which these systems may be based."

"We present work carried out within the framework of the Scriptorium project, developed at the Research & Development division of Electricité de France (EDF), the French electricity company. We are exploring issues related to knowledge acquisition from very large, heterogeneous corpora, and to the semantic annotation of these corpora, with the aim of facilitating browsing and navigation. Semantic access to heterogeneous, evolving text collections has become a crucial issue today in the world of online information: the increasing availability of electronic text enables the construction (and dispersion) of heterogeneous text collections. Current navigation tools such as thesauri, glossaries, indexes, etc., based on pre-defined semantic categories or taxonomies are inadequate for describing or browsing this kind of dynamic, loosely structured text collections. We therefore have adopted an inductive, data-driven approach aimed at extracting semantic classes from a corpus through the statistical analysis of textual data. We create different views or 'slices' of the document collection by extracting sub-corpora of manageable size, which we submit to the statistical software. We then build a navigable topic map of our document collection using the Topic Map Standard (ISO/IEC 13250) which provides a semantic interface to the document collection and enables navigation through the viewpoints and classes inductively acquired. Navigation is aided by a 3D geometric representation of the semantic space of the corpus... The aim of this project is to identify prominent and emerging topics from the automatic analysis of the discourse of the company's (EDF's) different social agents (managers, trade-unions, employees, etc.) by way of textual data analysis methods. The corpus under study in this project has eight million words and is very heterogeneous (it contains book extracts, corporate press, union press, summaries of corporate meetings, transcriptions of taped trade union messages, etc.). This diversity makes this corpus prototypical of the electronic documents available nowadays in a given domain. All documents are SGML tagged following the TEI (Text Encoding Initiative) recommendations... We are exploring issues related to semantic acquisition from large, heterogeneous corpora and content-based access to these corpora on the basis of inductively-acquired categories. We feel that data-driven, inductive approaches for building semantic interfaces to text collections will become more and more necessary, to efficiently manage the unrestricted, dynamic online information available today."

"Schema adjuncts are a mechanism for extending XML schema languages. To process XML instance documents for a given schema, many environments need additional information which is typically not available in the schema itself. Such information includes mappings to relational databases, indexing parameters for native XML databases, business rules for additional validation, internationalization and localization parameters, or parameters used for presentation and input forms. Some of this information is used for domain-specific validation, some to provide information for domain-specific processing. In either case, this information is best provided in a declarative manner, at the same logical level as the schema language. However, no schema language provides support for all the information that might be provided at this level, nor should it -- instead, we need a way to associate such information with a schema without affecting the underlying schema language. The Schema Adjunct Framework is an XML-based language used to associate task-specific metadata with schemas and their instances, effectively extending the power of existing XML schema languages such as DTDs or XML Schema... The power of the Schema Adjunct Framework derives from its simplicity and generality. We have presented three views of the Schema Adjunct Framework -- as a mechanism for extending schema languages, as a means for making XML processing applications generic with respect to schemas, or simply as a way to associate any kind of metadata with XML instance data. Since the framework places no constraints upon the information contained in adjunct associations, adjuncts can be applied to any problem that requires association of such information with a schema or with the structures it defines... The Schema Adjunct Framework is particularly useful as an integrating technology, defining characteristics of systems that do not belong to the universe understood by the schema language. For instance, in this paper we have defined relationships between an XML schema and the the relational representation of its data, the HTML forms that would be used to process instances, the indexes used to store instances in a native XML database, and a Java message queue that would process instances. In each of these scenarios, the schema adjunct defines a relationship between two different closed systems, which have no knowledge of each other. Schema languages describe structure of XML documents per se, without regard to external systems. Schema Adjunct Frameworks are often used to interface the XML representation to the universe of associated software. As an integrating technology, the Schema Adjunct Framework should prove particularly useful in environments that involve many loosely coupled systems, including web application frameworks, business-to-business integration solutions, and e-commerce architectures. Many of these environments use more than one schema language. Since the Schema Adjunct Framework can be used with any schema language, including DTDs, SOX, XDR, DCD, RELAX, or the W3C XML Schema specification, it is well suited to environments that must manage XML instances originating from many sources."

"The paper defines a convention for the use of UML to define XML documents. It uses UML stereotypes to map application-specific types to XML syntactic constructs. Shows how UML can be used in this way to map from abstract information data models to XML-specific implementation models in a natural and easy-to-understand way... The paper presents an approach to using UML (Unified Modeling Language) models to define XML (Extensible Markup Language) document types (DTDs - document type definitions or schemas). This use of UML serves as an alternative to other forms of 'XML schema'. The XML encoding of data is fundamentally an implementation representation of data that conforms to some higher-level abstract data model or object model. In this way, the use of UML to define the XML implementation of business objects is exactly analogous to using UML to define the Java or CORBA or C++ or SQL (Standard Query Language) implementations of those objects. Thus, for the purpose of this paper, there is assumed to be a more abstract data model of which the XML is an implementation, referred to as the 'XML implementation representation' of the data. We have two primary motivations for developing this approach to modeling document structure. First, as XML practitioners, we need a convenient and efficient way to develop and document document models in a way that is easy to communicate to both users of the system and implementors. Second, as system designers, we want a way to formally and tightly integrate the document model parts of our design into the overall system design, which is already modeled using UML (and, in our case, the Catalysis method of capturing multi-layered designs using UML). Thus, while this use of UML to model XML document types has immediate benefits as an alternative to DTD syntax or XML Schema, it has a much more profound long-term benefit as it enables the full integration of document models into larger system designs. A secondary motivation is using this model to help emphasize that XML is always an implementation view of more abstract data models and should not be used, by itself, as the one place where data models are captured or documented. In this paper, the term 'DTD' is used in the 'document type definition' sense, that is, the set of rules that governs the use of XML to represent sets of data that conform to a particular type, not in the 'document type declaration' sense, that is, the syntactic component of XML documents that provides the document's local syntax rules used by the XML parser when parsing the document. Using UML for the task of defining XML document types has a number of advantages, including: Enabling the clear and formal binding of abstract data models to their XML implementation representations Providing clear graphical representations of the XML implementation model Providing true modularization of DTDs through UML's normal package mechanism. Enabling the use of generally available tools with which most programmers have at least some passing familiarity (e.g., Rational Rose, ObjectDomain, etc.) Providing the opportunity for information modeling and implementation activities to take advantage of UML-based design and modeling methodologies such as the Catalysis method. More effectively and directly binding of the documentation for the element types to the model definition. The document is a first-class part of the model rather than being either just comments in the declaration set or a completely separate document that is not tightly coupled to the formal DTD definition. Using XMI (XML Metadata Interchange) for the storage of the UML models, arbitrarily sophisticated XML structures can be used within the XMI data set to model the documentation... This paper first presents the definitions of the stereotypes, formally defined through a UML model in which the stereotypes are types, then demonstrates how those stereotypes are used using a simple demonstration DTD. The paper assumes that you are familiar with both UML and XML syntax and concepts. Note that as presented in this paper all the models are data models, not object models, meaning that they define static types. However, the data models could be further refined into object models that provide methods for the types. This paper does not address this aspect of using UML to model documents and document types... It should be clear from the sample document type that UML can be used productively to directly model XML DTDs using normal UML techniques. Additional work to be done includes: (1) Refine the use of specific UML syntactic facilities and conventions. For example, is an element type a refinement of a more abstract type or is it an implementation?]; (2) Refine the content constraint language; (3) Gain more practical experience with using this technique in real-world situations; (4) Refine the use of Catalysis methods and conventions (templates, refinement, etc.) in this model."

"Programming XML applications in Java provides developers with a wealth of Java software available for creating and manipulating XML. Much of it is freely available from the Web, and can even be used commercially for no charge. Java APIs for XML There are four different Java APIs (Application Programming Interface) commonly in use for parsing documents: SAX by David Megginson, DOM from the W3C, JDOM by Brett McLaughin and Jason Hunter, and JAXP from Sun. To process XML documents you will need to access them through one of these Java APIs. SAX (The Simple API for XML) is in its second revision. SAX uses an event based parsing model, calling methods into your application for every significant XML token appearing in the document. Several parsers implement the SAX APIs, includes Xerces from Apache, XP from James Clark, XML4J from IBM and the Project X parser from Sun included in the JAXP 1.0 release. A very simple SAX parsing application does not use any callbacks, and looks ....Of the four APIs that have been discussed, JDOM is the most complete API, but the software is still in the Beta testing stage. For simple XML processing applications, it is the simplest and easiest way to handle XML processing in Java. The other three APIs, SAX, DOM and JAXP, are very complimentary. Together they make up an almost complete API for processing XML in Java, although XML output is still missing. The SAX API provides mechanisms to load and parse documents, making up for these deficiencies in the DOM. The DOM APIs provide a mechanism to create and edit documents in memory, which is a capability missing from SAX. Finally the JAXP APIs provide a uniform way to instantiate parsers and implementations, a feature missing from the other two. Most Java parser implementations today use two or more of these APIs together, and I expect that all of these standards will someday converge into a complete Java API for XML..." A review essay of Java and XML (by Brent McLaughlin) and Java and XML (by Hiroshi Maruyama, Kent Tamura, and Naohiko Uramoto).

This book [DocBook - The Definitive Guide] is available on the Web, right? It's probably up to date with all the errata fixed, right? Other than for the obvious I like the paper feeling, I personally like to have the reference information sit on the side of my keyboard while I key in my document. I find it highly commendable of O'Reilly to allow the content be available on the Web as a reference, and I wish more publishers would emulate them. Indeed, the content is not only available on the Web, it is also on a CDROM that comes with a book, which contains the book in HTML, in MS Help format, and in SGML. All the examples of the book are in source form, and for some added value, style sheets in XSL and DSSSL are also included. Some utilities (EXPAT, Jade, XP, XT) are also thrown in so you don't waste time looking for them and you can get started at writing your DocBook documents right away. The spirit that guides that book, its content and its packaging can be summarized in one word: Practical. No effort was spared to make the book usable, and its content reusable. Besides the obviously well-mastered knowledge of the authors on the content, the reader finds a plethora of useful hints about DocBook (but also about SGML, XML and DSSSL) to make the DTD user's life much more comfortable. There is also a fairly extensive section on the customization and maintenance of the DTD which will appeal to the document administrator, but also to any DTD designer, DocBook representing state-of-the-art DTD modeling. The book is divided into the following three parts..."