The Extensible Markup Language (XML) is an open, general-purpose specification for creating markup languages. Its primary purpose is to help information systems share structured data, particularly via the Internet, and it is used both to encode documents and to serialize data. It is used in a wide variety of technical communication document formats, including Microsoft Word, OpenOffice, XHTML, DITA, DocBook, and RSS, among others.
As published the W3C XML Schema specification references XML 1.0 explicitly, and incorporates by reference certain key definitions, in particular those of the 'Char', 'Name' and 'S' character classes. XML 1.1 changes the contents of these classes, so although nothing in the existing XML Schema specification specifically bars infosets produced by XML 1.1 conformant parsers, such infosets, if they exploit any of the relevant changes in XML 1.1, will not be accepted as valid by conformant XML Schema 1.0 processors.
Collaboration between designers and developers is always great topic to write about. I believe that for the first time that kind of collaboration is possible to full extent and it is possible today. Key element for enabling this is XAML – eXtensible Application Markup Language aka Holy Grail of designer – developer collaboration.
The Adobe XML architecture combines the powerful data and business logic capabilites of XML with rich presentation capabilities of Portable Document Format (PDF). The Adobe XML architecture offers support for arbitrary XML, allowing you to leverage existing and industry-standard schemas. Depending on the process requirements, forms can be deployed as PDF or an XML Data Package (XDP) and processed as XML.
XSLT stylesheets are designed to transform XML documents. Coupled with Java extensions, stylesheets can also be a powerful complement to XML Schema when grammar-based validation cannot cover all the constraints required. In this article, Peter Heneback presents the case for validating documents using XSLT with Java extensions and provides practical guidance and code samples.
Three panellists talk about how they've applied agile development techniques to XML, followed by audience discussion and Q&A: Tony Coates will discuss XML and schema quality assurance using unit test frameworks. David Carver will discuss agile XML schema development. Claudia Lucia Jimenez-Guarin will discuss software construction for evolving systems with incomplete data definition.
XML editors have traditionally been modeled after the first SGML editor written in 1985, a long time before creating, managing, and distributing structured information was well understood. Now, nearly 20 years later, there are more choices for users interested in creating structured information. Specifically, this presentation discusses alternatives that include Web-based distributed collaborative XML document creation, "tag-free" tools, non-formatting structured editors, and even using common office tools in creating your XML documents.
While I'm a big fan of XML for many purposes, it's a misconception that it's the single best solution in every scenario, and it's worthwhile to consider the alternatives in situations where the benefits of XML are not necessary. In this article, I discuss alternatives to XML, SGML, and HTML that might be suitable when budgets are more limited. While XML is perfect for highly coded information, other options can work well for many kinds of information. Markup languages are at the high end of the cost spectrum, so if you don't need the benefits they provide, you certainly should consider the alternatives discussed below.
Writing, compiling, and maintaining documentation is a necessary evil. While moving to DITA might not improve the quality of your documentation, it can streamline the process of creating and managing those documents.
Creating an XML-based Content Management System to single-source technical publications is as simple as 1 - 2 - 3. OK, maybe it isn't quite that easy, but this article discusses how it can be done.
Currently, visual XML structured authoring applications can typically handle a small number of XML vocabularies. In some cases, they can even handle them in limited nested scenarios. One of the purposes of creating XML documents with compound vocabularies is to present related information on a given topic in different manners (tables, charts, etc). The synchronization of views between objects of different vocabularies in real-time editing helps authors realize this potential. In this presentation we will discuss an approach to visually creating, editing and synchronizing, nested compound XML vocabularies within one document. The open nature of the architecture enables developers to create plug-ins for new vocabularies including the ability to define synchronization. Also this architecture provides simple method to define visualization of a new vocabulary by utilizing plug-ins already developed and activated.
Learn from Dr. JoAnn Hackos, President of Comtech Services, Inc. and Director of the Center for Information-Development Management (CIDM), how to evaluate your legacy content and assess how close you are to the DITA standard. Understand the decision-making process you need to follow to prepare for the conversion process. Consider if your team should first restructure your content in your current tool environment or wait to restructure and rewrite following conversion.
The domain model is a familiar concept to most OOP (Object Oriented Programming) developers and architects, and has been used successfully in a variety of systems and projects. But how does this principle apply to SOA-based solutions?
XUL is a surprisingly easy way to build cross-platform browser extensions or even stand-alone applications. Discover how to build powerful, flexible Mozilla browser extensions that go beyond the capabilities of other tools like embedded scripting languages or CGI--because they're built right into the user's browser.
As techcom professionals, we have been talking about authoring in XML for a very long time. At first, it was a lot of hype about a format that required major programming skills and had zero tools’ support, but that is now changing. Today, there are hundreds, if not thousands, of tools that support XML and a standard called DITA that is in constant development to support content publishing for different industries. As a result, more and more companies seem to be embracing this content format.If you are a writer or techcom manager who is encouraging your company to make this change, then what do you need to know to prepare?
The topic of technical publishing is relatively new to the world of Eclipse. One can make the argument that technical publishing is just another collaborative development process involving several people with different backgrounds and skills. This article will show that the Eclipse platform is a viable platform for technical publishing by discussing how to write documents such as an article or a book within Eclipse. In fact, this article was written using Eclipse.
XML topic-based documentation enables consistency, reuse, conditional publishing, separation of content and styling, and more. A good XML solution makes it easier for the authoring teams to move to XML authoring, providing structured templates, embedded editors, maintaining links and metadata, and adding collaboration features such as workflows.
Since the early days of XSLT, many have asked whether it was possible to automate the creation of XSLT stylesheets. The general idea of filling out a form or dragging some icons around, then clicking a button and seeing a productive stylesheet generated from your input has always appealed to people. However, the problem of generating working XSLT syntax from the result of someone clicking on pull-down menus and radio buttons has not attracted many takers.
As a member of my country's national standards body committee on electronic data processing, I lately spend considerable time deliberating what our position should be in the upcoming Office Open XML ISO Ballot Resolution Meeting in Geneva. My biggest objection concerns large parts of the standard that are proposed to live in an Annex containing normative descriptions of deprecated features that will only be used by existing binary documents. The rationale behind this decision is backwards compatibility. My opinion is that this solution is counterproductive for a number of reasons.
As an independent consultant working mainly with small businesses I find that my clients are reluctant to commit to DITA for a number of reasons. As DITA authoring tools become more user-friendly and more readily available some of these barriers will begin to fade. But in general terms, the more DITA tools that become available, and the easier they become to use, the better for everyone.