Copyright © 2002 Garret Wilson. All Rights Reserved.
In many ways the issue of style provided the first harbinger of the XML package problem. Even with its roots in SGML, for which grizzled academics had spent countless years to be able to encode the world itself inside custom markup, XML in 1997 was popularized as being "like an HTML, but you can make your own tags"—and everyone knows that HTML integrates presentation information into its tag set tighter than those high-level rolled-up dimensions of superstring theory. For XML to succeed, it had to come with a backward glance to HTML yet needed to look forward towards elegance and reusability.
HTML's <i> tag should be displayed in italics, of course—but what does italics attempt to relate? If the meaning behind the font were known, could not that meaning be somehow conveyed in other ways for systems without italic fonts and to users with visual disabilities? In order to somehow break out the boldness of the <b> tag, yet maintain the semantic clarity of <code>, HTML's guardian, the W3C, advocated a distinction of an XML document's meaning and the way it is presented—a separatation of content and presentation, one of the many mantras of the semantic encoding faithful.
Removing the style information and denoting it elsewhere was a significant but small hurdle. By the time XML came into being in 1998, the first version of the Cascading Style Sheet (CSS) specification already illustrated how to add custom style information to HTML, and the natural next step was to use the new CSS Level 2 [CSS2] to indicate, for example, that "those custom tags you made" in XML should be bold, superscript, or even enclosed in the nicest little borders. Linking a CSS stylesheet to the HTML document was made convenient by the presence of the HTML <link> element, but the power of XML's "build your own" toolkit approach meant that XML had no tags already built for such a task.
On the face of it, linking styles to XML seemed a simple problem to solve, but it wasn't until over a year after the release of XML that the W3C released in 1999 a recommendation for Associating Style Sheets with XML Documents, and even that was seen as a "simple mechanism closely based on a proven existing mechanism", released only so the specification could "be completed in time" [XML Style Sheets]. Elements such as <link>, in the words of the Consortium, "pollute the main document structure with application specific processing information", and so it was decided to provide style linking through a special XML processing instruction with an almost identical syntax that, although appearing inside an XML document, nonetheless appears outside the central markup.
A large portion of the relatively small [XML Style Sheets] is devoted to disclaimers such as, "style sheets may be linked with an XML document by means external to the document", and ends with the ominous,
The mechanism chosen for this version of the specification is not a constraint on the additional mechanisms planned for future versions. There is no expectation that these will use processing instructions; indeed they may not include the linking information in the source document [XML Style Sheets].
And rightly so, the presence of those disclaimers, for in the minds of the semantic/presentation purists such a stylesheet linking method could only be a stop-gap measure. However nicely XML processing instructions remove stylesheet linkage from the tags of an XML document, it nevertheless remains that those processing instructions live in the same physical XML document as do those tags the stylesheet claims to represent. While succeeding in removing style description from an XML instance, [XML Style Sheets] still left style irrevocably linked to a particular element collection, negating many of the benefits such separation was supposed to bring. This single problem brought to light a larger, undeniable realization: one must take into consideration the larger world of things with which XML documents interact.
It was in this setting that the W3C recognized that "there is a great need for a general purpose packaging mechanism for XML and related files", and in late 1999 drafted the charter for a new working group devoted to creating such a mechanism [W3C XML Packaging WG Charter]. While citing stylesheet linking as included in the foremost use case of this sort of packaging, the draft charter noted Michael Sperberg-McQueen's insight into the larger issue of document association:
Stylesheet linkage is one prominent instance of a large class of problems, related to the question of locating metadata relevant to processing a particular document in a particular way. When that problem is solved, other similar kinds of metadata will take center stage. The problem of locating a Dublin Core description of a document, or some other RDF metadata, will be the hot question. Then the problem of locating the schema, or a schema in a particular notation or schema language. And then the next flavor of the week. The best solution to this problem, as was recognized a long time ago in discussions of the XML work group (at least my memory says it was long ago), would be to define an application for packaging this kind of information [Sperberg-McQueen, as quoted in W3C XML Packaging WG Charter].
The draft charter of the W3C XML Packaging Working Group defined a collection as a group of "things" (such as XML documents and stylesheets), with each of those things described as a component of the collection. A relationship between components in a collection is an association; in their terms, an XML document component and a stylesheet component would together form an association. Central to the idea of packaging was a manifest, which consisted of a compilation of descriptions explaining the various components stored in a collection, and the associations between them.
Implicit in the XML Packaging Working Group's early view are two aspects of packaging: the description of components and associations; and the physical bundling of those components and associations into a single file. By the working group's definitions, such a physical bundling would be a package, and might be compressed. Although compression in itself seemed to be a task with many unresolved issues, the group saw both description and bundling as within its scope. Ultimately the W3C addressed neither of these; as momentum faded in favor of other pressing needs, the XML Packaging Working Group was never realized.
Discussion of a syntax for packaging had begun long before those "discussions of the XML work group" of Sperberg-McQueen's reminiscings. Prior to XML, the W3C, and even the Internet, David Crocker at the University of Delaware proposed a Standard for the Format of ARPA Internet Text Messages. This Request for Comments #822, published in 1982 [IETF RFC 822], became the basis for every e-mail message that currently speeds through the copper and fiber veins of the Internet. Itself a revision of a 1977 proposal, RFC 822 prescribed headers, separate from the message itself, that consist of field names and field values.
Field name and value pairs have become as recognizable as the phenomenon called e-mail with which they were conceived. Every computer novice writing to an Aunt Idabell in Idaho has first made sure Auntie's e-mail address appears next to the "To:". Maybe Uncle Erwin's e-mail address is stuck next to the "Cc:", with a "Subject:" of "Thank you for the silk socks," the best birthday present of them all. As e-mail evolved, the field names available expanded to include more behind-the-scenes management through the Multipurpose Internet Mail Extensions (MIME) [IETF RFC 2047]. MIME makes e-mail attachments possible (a picture of those socks actually being worn, for instance) without straying from the simplicity of field names and field values. Years before the W3C formally considered packaging, e-mail through MIME had creating a packaging structure, based upon simple name and value pairs, that was being proven by a world of Internet users.
As a lowest-common-denominator technique for pushing messages through the diversity of equipment on the Internet, e-mail has served its purpose well. For long-term, compressed storage and exchange that allows for random access, the format breaks down—not because of a failure of the name-value paradigm but because of the framework in which that paradigm is embedded. When permanent storage, compression, and random access arose as requirements for storing Java files, for example, Sun Microsystem elected to use a standard compression format called Zip [ZIP] to serve as the storage aspect of Java class packaging in the Java Archive (JAR) format [JAR]. To provide the other half of packaging, the description of included files, Sun created a special META-INF directory inside the Zip file containing a MANIFEST.MF file.
Inside MANIFEST.MF Sun simply reused the header format of RFC 822, calling each name and value pair an "attribute". By using a separate manifest file, the content description could be separated from the actual storage of the content. A sample JAR might include something like the following:
Manifest-Version: 1.0 Created-By: 1.3 (Sun Microsystems Inc.) Main-Class: org.openebook.test.TestApplication Sealed: true Name: org/openebook/common Sealed: false Name: resources/images/image1.png Content-Type: image/png
The JAR format, as simple and as unoriginal as it may first appear, nevertheless embodies several powerful packaging concepts: the separation of content description from the content itself, the separation of content description from the content storage method, and a name plus value pair method of describing content. Additionally significant is Sun's naming of the manifest directory META-INF, i.e. "meta-information" or "metadata". Rereading Sperberg-McQueen's original packaging statement ("other similar kinds of metadata... [such as] a Dublin Core description of a document, or some other RDF metadata... define an application for packaging this kind of information") suddenly gives the story away: content packaging information is really just metadata about the content. But the implications of this comes later in the story.
In late 1998, as the Internet economy expanded its bubble to seemingly neverending proportions, several companies including Microsoft, Softbook, and Nuvomedia began trying to foster consumer acceptance of electronic books, or eBooks. Taking a cue from the ever-popular MP3 format for music, and alluding to the infamous BETA-VHS wars of times past, these companies founded the Open eBook Authoring Group (now the OEB Forum, http://www.openebook.org) for creating a standard publishing format for a future eBook industry. As did the JAR format, the OEB Publication Structure 1.0 produced by the Group leveraged existing specifications: XML was used as the a base syntax, a variant of HTML was used for markup, and CSS was used for denoting style information [OEBPS1].
One component of the OEBPS was a complete innovation, in syntax if not in concept: the OEB Package File. Structured as a separate XML document, the OEB package file contained several sections inside XML elements; these included <metadata>, <manifest>, and <spine>. The metadata section allowed metadata to be associated with the OEB publication itself, through standard Dublin Core property XML syntax [DC], but did not allow metadata to be associated with each OEB Document (which was essentially an HTML document that composed part of the publication). The manifest contained references to the actual OEB documents used, while the spine expressed their order. This resulted in a package file structure similar to the one below (modified for illustration):
<package> <metadata> <dc-metadata> <dc:Title>Sample OEBPS1 Package</dc:Title> <dc:Creator>Garret Wilson</dc:Creator> <dc:Date>2002-02-08</dc:Date> </dc-metadata> </metadata> <manifest> <item id="preface" href="preface.html" media-type="text/html"/> <item id="chapter1" href="chapter1.html" media-type="text/html"/> <item id="chapter2" href="chapter2.html" media-type="text/html"/> <item id="fancy" href="stylesheet.css" media-type="text/css"/> <item id="picture" href="image1.png" media-type="image/png"/> </manifest> <spine> <itemref idref="preface"/> <itemref idref="chapter1"/> <itemref idref="chapter2"/> </spine> </package>
The manifest referenced all the files needed by the OEB publication, but gave little information about them. The OEB Authoring Group needed to expose the MIME type of each file, so a media-type attribute was provided for each item in the spine. In a step back from the ubiquitous MIME and JAR formats, however, no mechanism was given for arbitrary information about each file. The closest one could get to field name and value attributes were in the metadata section, but only for the publication as a whole: Dublin Core metadata could be provided, as well as metadata extensions in a separate sub-section.
Remarkably, another group called the IMS Global Learning Corsortium, Inc. (http://www.imsglobal.org) during the same timeframe was constructing a packaging framework very similar to that of the OEBF. The IMS Content Packaging [IMS Content Packaging] format was originally conceived to store Question and Test Interoperability (QTI) information for assessments [QTI], and also includes a metadata section, along with a manifest section containing items. Instead of a "spine", the IMS model refers to an analogous "organization" section that specifies the order of items within the package. The similarities between IMS Content Packaging and the OEB Package are obvious, as illustrated by the example below (modiifed for illustration):
<manifest> <metadata> <schema>IMS Content</schema> <schemaversion>1.1</schemaversion> <imsmd:record> <imsmd:general> <imsmd:title> <imsmd:langstring xml:lang="en-US">Sample IMS Content Package</imsmd:langstring> </imsmd:title> <imsmd:contribute> <imsmd:role> <imsmd:langstring xml:lang="en">Author</imsmd:langstring> </imsmd:role> <imsmd:centity> <imsmd:vcard>BEGIN:vCard FN:Garret Wilson N:Wilson END:vCard</imsmd:vcard> </imsmd:centity> <imsmd:date> <imsmd:datetime>2000-02-08</imsmd:datetime> </imsmd:date> </imsmd:contribute> </imsmd:general> </imsmd:record> </metadata> <resources> <resource identifier="preface" type="text/html" href="preface.html"> <file href="preface.html"/> </resource> <resource identifier="chapter1" type="text/html" href="chapter1.html"> <file href="chapter1.html"/> </resource> <resource identifier="chapter2" type="text/html" href="chapter2.html"> <file href="chapter2.html"/> </resource> <resource identifier="fancy" type="text/css" href="stylesheet.css"> <file href="stylesheet.css"/> </resource> <resource identifier="picture" type="image/png" href="image1.png"> <file href="image1.png"/> </resource> </resources> <organizations> <organization> <item identifierref="preface"><title>Preface</title></item> <item identifierref="chapter1"><title>Chapter 1</title></item> <item identifierref="chapter2"><title>Chapter 2</title></item> </organization> </organizations> </manifest>
The packaging frameworks for both the OEB and the IMS were made to fill immediate needs. The OEB found itself with XML documents, images, and stylesheets that needed to be bundled together into an eBook. The IMS inherited a rich XML vocabulary for assessments and tests that, although agnostic of stylesheets, still required images, video, and sound.
The immediate usefulness of these framework in some ways forecast their inflexibility, however. The OEB's choice of the term spine assumes the context of a book, and only book-related content (specifically, an OEB document) is allowed inside a spine. The IMS presumes a pedagogical assessment-centered context, and parts are not rigorously defined for general use. (Indeed, most IMS examples of "type" simply use a semantically useless value of "webcontent"). Neither model recognized the pivotal style-association issue, and both allowed inclusion of custom metadata only through a cumbersome syntax.
Requirements and specifications both change with time, and as the Open eBook Forum began to explore its next-generation features, the first-born package structure was found in need of evolution. OEB and its anemic HTML subset needed an infusion of other vocabularies: MathML, TEI, SVG, and MLs not yet invented. A newer model OEB processing application would need to know, simply by reading the package information, exactly which vocabularies were used inside OEB documents, but the older-model package provided no such indications.
The initial proposal called for a teething of the OEB package: a new attribute denoting XML namespace (call it namespace, perhaps) would be added to the OEB <item> element specification, allowing any namespace to be named. One good attribute deserves another, and soon stylesheet association, which has been lurking in the back of our story since the beginning, was added to the list. An attribute here, an attribute there—"Why not standardize on XLink while we're at it?" A committee was tasked with exploring item specification through XLink [XLink], and its report recommended (as those things often do) a radical shift: "Why not use XLink for the whole thing?"
XLink provides the concept of an extended link in which one element list various things called resources and then prepares to link them all together in a sort of connect-the-dots fashion. Complex relationships, however, quickly turn into a one-level hierarchy of package spaghetti-code, and if its flattened view of the world didn't in itself derail the "XLink for everything" movement in the OEBF, it needed little help from the illegibility concern lying across the tracks. The specter of the makeover cat had long since escaped and refused to go back (into the <rdf:Bag>, as it turns out), and so the Resource Definition Framework [RDF] of the W3C was put forward as an alternative to XLink.
RDF is a framework that also talks about resources—in fact, in the world of RDF, everything is a resource. XML documents are resources. Stylesheets are resources. Ditto images. Each resource can have one or more properties, and yes, the values of those properties are also resources. Even the properties themselves are resources.
In practice, this property and value pairing is simple: each resource has a property such as "author", which has a value such as "Garret Wilson". RDF is already the most popular carrier of the Dublin Core metadata, familiar to both the OEBF and the IMS. If a Dublin Core value were to be represented as "author: Garret Wilson", it would be immediately recognized as the old acquaintance from MIME, the field-value pairs. RDF was made by academics, though, and chooses to be somewhat more cryptic: each resources is identified by a unique URI, and since everything (even properties) are resources, URIs are used to identify them as well. This reduces the simplicity of fields and values to something like, {http://purl.org/dc/elements/1.1/author, "Garret Wilson"}, but the concept remains the same.
Just to be more complicated, RDF says that {http://purl.org/dc/elements/1.1/author, "Garret Wilson"} specifies the same thing as the "author: Garret Wilson" in the Dublin Core, but does not say which object has that property— that is, "Garret Wilson is the author of what?" The academic description of RDF, then, uses a triple that identifies the resource being described. If we assume that this article has the unique ID of http://garretwilson.com/articles/xpackage, RDF would prescribe a triple of {http://garretwilson.com/articles/xpackage, http://purl.org/dc/elements/1.1/author, "Garret Wilson"}: "This article has an author (as specified by the Dublin Core) of Garret Wilson." Referring to that as-yet unfinished e-mail to Aunt Idabell, RDF would change "To: Aunt Idabell" into the more cryptic {some unique URI of the e-mail message, some unique URI for "to:", "Garret Wilson"}.
RDF triples, however, are from the academic RDF description. Normal use of RDF within XML is much simpler. Specifying the author of this article would appear something like this:
<rdf:Description about="http://garretwilson.com/articles/xpackage"> <dc:author>Garret Wilson</dc:author> </rdf:Description>
That simple depiction of metadata, already used in OEB for the Dublin Core properties, includes features more powerful than the simple MIME field name and value pairs:
<extension> section for metadata—RDF metadata from diverse vocabularies can be combined anywhere.That last point is possibly the most powerful for a package. Before adding metadata as some afterthought to a package specification, remember that everything the package describes is metadata. To specify that an XML document "article.html" has a sylesheet of "stylesheet.css" is no different than saying that "article.html" has an author of "Garret Wilson". If the entire package is described in RDF, an RDF processor can automatically understand the whole of the package data as one integrated graph of resources and their properties—even without any knowledge of the packaging specification apart from RDF. (The W3C's [W3C RDF Validator], for instance, could process and produce a graph of any RDF-based framework, without knowing ahead of time whether Dublin Core, some packaging framework, some unknown RDF-based information, or a little of each is being used.) It is this power, similar to the the consistency brought by XML itself, coupled with the need for a general-purpose packaging framework, that conceived the OEB Package's younger but wiser sibling: XPackage [XPackage].
Before RDF, before XLink, before XML ("like an HTML, but you can make your own tags"), there was HTML. Somebody made the tags for HTML, and those somebodys include the earliest of authors, Tim Berners-Lee, along with others from the W3C team: Dan Connolly, Dave Raggett, Arnaud Le Hors, and Ian Jacobs [HTML4]. In 1995, HTML was only at version 2.0; the browser wars, fueling the addition of a custom flavorful tag each week ("like an HTML, but it only works in our browser"), were only getting started. Tim Berners-Lee and Dave Raggett sat pondering tags to add in the next generation of what had become their HTML.
"How about a tag to refer to generic resources?" one of them asked. "By that," he continued, "I mean the ability to transmit within an HTML document information about other documents, such as images and stylesheets."
"But of what use would that be?" the other must have questioned. "Don't we already allow images to be included through the use of the HTML <img> tag, and can't we already associate with stylesheets through the use of the <link> tag, both of which, I might add, seem quite aptly named?"
"Yes," the first countered in our hazy reconstructed dialogue, "but those tags are each quite specific to a specific application; each a highly specialized..." and at this point it is possible, just possible, that the words, "...flavor of the week, so to speak..." crossed his mind as he (Tim? Dave?) finished with the words "...that don't and couldn't apply to the multitude of things that might need to be described in the future."
"Besides," he continued (and at this point the words are actually recorded [Resources in HTML]), "there is a need to be able to specify within a document two alternative renderings of an image, for example one animated and one (failing animation) still image... There is a need to be able to specify a set of optional style sheets, for operator selection..."
Yes, and yes. We know that now. But he continues still.
"There is a requirement to be able to convert between information expressed in RFC822-style headers as in the HTTP protocol's object headers..." Those field names and values of [IETF RFC 822] again. It was then, in 1995, before RDF, before XLink, before XML, when there was only HTML ("in which we, the W3C create the tags"), that two members of the W3C, in a "scribbled note... for use of W3C team..." [Resources in HTML] suggested a new tag named <resource> that would be used like this:
<resource href="myimage.png"> <meta http-equiv="Content-type" content="image/png"> </resource>
Fallbacks are there:
<resource href="myimage"> <link rel="content-type-specific" href="myimage.png"> <link rel="content-type-specific" href="myimage.gif"> <link rel="content-type-specific" href="myimage.avi"> </resource>
Multiple optional stylesheets, too, are listed in this pre-RDF, pre-XML, pre-XPackage note that most have forgotten, the idea of a new tag that never saw the light of an HTML specification. And so this general solution was discarded, making room for more "flavors of the week", as Sperberg-McQueen called them, to address specific needs.
Over the years, the use of XML propogated and evolved, and a partitioning mechanism called namespaces ("like normal XML, but you can create your own tags and put them in a namespace so they can be yours, all yours, and have whatever meaning you assign them") came into vogue. Namespaces, like RDF resources, are identified by a unique URI, but this URI, according to [XML Namespaces], need not actually refer to any actual document—it's for identification, no more, no less.
Tim Bray was not one of the original authors of HTML, but was one of the co-creators of XML (alongside others including Sperberg-McQueen, it might be added). As the use of namespaces proliferated, it dawned on Tim and others on the xml-dev mailing list that a namespace's identifying URI could point to something, something that would tell more about the namespace. This description of the namespace could give "human-readable descriptive material about the target", and "a directory of individual resources..." (resources again) "...related to the target, each directory entry containing descriptive material and linked to the resource in question."
Such was the premise of the Resource Directory Description Language [RDDL] proposed by Tim Bray and Jonathan Borden: a language that would allow describing the various resources, such as "schemas and stylesheets..." (style again) that are associated with an XML namespace. Tim and Jonathan, following in earlier footsteps, decided to create a new element, <rddl:resource> that would be part of modularized XHTML ("it is HTML, and you can nonetheless create your own tags"). They settled on XLink as a framework for encoding the resource descriptions.
RDDL uses the XLink attribute xlink:role to indicate a nature—an RDDL-specific animal that resembles a MIME media type, is used like a MIME media type, but is much more specific (a duck with its size, shape, and weight defined). The XLink attribute xlink:arcrole specifies the purpose of the resource, the RDDL aspect that signifies why the resource is important to the namespace, taking values such "validation", "notation", or "entities".
XLink is a very useful but restricted tool, and when pushed to its limits quickly becomes too top-heavy, as the Open eBook Forum found when searching for new ways to represent packaging descriptions. RDDL, however, was made for a well-defined use case, one currently still within the bounds of XLink: describing the nature and purpose of resources that are related to a namespace. A stylesheet might have a nature of http://www.isi.edu/in-notes/iana/assignments/media-types/text/css (a content type of text/css in a format built for extension, should it ever be needed) and a purpose of "style", although RDDL would say that in this case, the nature gives away the purpose, making the latter redundant.
Use cases seem to grow and produce offspring as time passes. While XLink may be serving the purposes of RDDL well for the time being, what needs will arise that will require expansion of RDDL? Will such expansions encounter into the same limitations as did the original Open eBook packaging structure, requiring arbitrary custom attribute additions? Already many resource description needs are present, some having been evident since at least 1995:
RDDL is usable for specific purposes, but as a general framework it quickly meets it limits. RDDL can only be applied to its particular problem domain, the description of XML namespaces; it cannot easily transition to provide directories for archives, to provide an eBook publication manifest, or to specify how an XML file and its namespaces, images, and stylesheets all relate. The words of Bray's co-author of XML, Sperberg-McQueen, come floating back hauntingly through the mist-filled air:
...And then the next flavor of the week. The best solution to this problem, as was recognized a long time ago in discussions of the XML work group..., would be to define an application for packaging this kind of information [Sperberg-McQueen, as quoted in W3C XML Packaging WG Charter].
It is this need that XPackage seeks to fill.
XML has always been portrayed as a set of building blocks, a markup toolkit ("like an HTML, but you can make your own tags") the very name of which cries out, "extend me!" The Extensible Markup Language [XML] it certainly is, at least in syntax, but nothing in XML gives any hints to the meanings of any of the endless ML variations that purport to encode math, to represent business transactions, and to allow intra-object communication. Any added XML, without some third-party definition, is devoid of meaning, and this has predictably resulted in a plethora of new languages that are redundant but inconsistent and overwhelmingly non-interoperable.
RDF is not an ML. RDF is an academic mental excercise, a tale that recounts:
There existed a land where everything was a resource. The knight was a resource, as was the castle in which he lived. Likewise his trusty steed, Nelly, which happened to be a property of the knight. This land at one time, for lack of better words, was described by such triples as {
http://medieval.org/knights#lancelot,http://medieval.org/properties#steed,http://medieval.org/steeds#nelly}.All the inhabitants of the land could hardly talk among themselves without becoming immediately bored and confused. They petitioned the king to invent a new language that did not consist entirely of triples. The king questioned the wizard ("well, they call me a computer wizard"), who, hardly glancing up from writing his newest program, gave an answer that all wizards have been giving ever since: "We'll use the same language, we'll just encode it in XML, since that's what everyone else is using."
RDF is not an ML—but it can be portrayed or serialized in XML. The RDF specification includes strict (though some would say not strict enough) instructions for how to discuss resources and properties using an XML serialization [RDF]. In truth, every RDF+XML document is an extension of RDF, just as every XML document is an extension of XML. The RDF rules, however, say explicitly what role the extensions play. Pick out any portion of an RDF+XML document, and it will be unambiguous whether that "thing" is a resource being described, a property of a resource, or a property value. All that's needed is an ontology to explain, for example, what a "knight" means—it's already obvious, in RD+XML, that the knight is a resource with properties.
XPackage is just such an RDF ontology. It describes several resources and properties, and explains how they can be used in RDF+XML. A sampling includes:
<xpackage:resource><xpackage:package><xpackage:manifest><xpackage:organization><xpackage:contentType><xpackage:location>The earlier examples recast as an XPackage document (in XPackage terms, a package description document) looks hardly changed, except for a couple of unknown elements, <rdf:Bag> and <rdf:Seq> which are ancillary to this discussion:
<xpackage:description> <rdf:RDF> <xpackage:package rdf:about="urn:oeb:samplepackage1"> <dc:title>Sample OEBPS1 Package</dc:title> <dc:creator>Garret Wilson</dc:creator> <dc:date>2002-02-08</dc:date> <xpackage:manifest> <rdf:Bag> <rdf:li rdf:resource="urn:oeb:samplepackage1-preface"/> <rdf:li rdf:resource="urn:oeb:samplepackage1-chapter1"/> <rdf:li rdf:resource="urn:oeb:samplepackage1-chapter2"/> <rdf:li rdf:resource="urn:oeb:samplepackage1-stylesheet"/> <rdf:li rdf:resource="urn:oeb:samplepackage1-image1"/> </rdf:Bag> </manifest> <xpackage:organization> <rdf:Seq> <rdf:li rdf:resource="urn:oeb:samplepackage1-preface"/> <rdf:li rdf:resource="urn:oeb:samplepackage1-chapter1"/> <rdf:li rdf:resource="urn:oeb:samplepackage1-chapter2"/> </rdf:Seq> </xpackage:organization> <rdf:RDF> </xpackage:description>
Note that XPackage requires no separate metadata section for the Dublin Core properties, because everything is metadata. The <xpackage:manifest> and <xpackage:organization> elements indicate properties of the package, just as do <dc:title>, <dc:creator>, and <dc:data>. Creating an extension to XPackage is trivial—after all, XPackage and Dublin Core are both extensions of RDF. The yet to be released Open eBook Publication Structure 2.0, for instance, extends the idea of a package and uses a special <oebps:publication> resource in place of <xpackage:package>, above. From the view of an RDF+XML processor, it's obvious in both cases that <xpackage:package> and <oebps:publication> are resources with properties, with no prior knowledge of the XPackage or OEBPS ontologies required ahead of time.
It's apparent that some information is missing in the above example that was present in earlier examples: the MIME content type and location of the preface, chapters, stylesheet, and image. (Closer inspection above will reveal that the URIs given above are not locations but identifiers.) To RDF and XPackage, this is no surprise: MIME content type and location are resource properties, and should therefore be indicated in relation to each resource being described. Instead of specifying content type and location as arbitrary attributes, they are shown to be true properties of their respective resources—in such a way that an RDF+XML processor will immediately identify them as properties. Three such descriptions—for the first chapter, for the stylesheet, and for the image—are shown below:
<xpackage:resource rdf:about="urn:oeb:samplepackage1-chapter1"> <xpackage:location xlink:href="chapter1.html"/> <xpackage:contentType>text/html</xpackage:contentType> </xpackage:resource> <xpackage:resource rdf:about="urn:oeb:samplepackage1-stylesheet"> <xpackage:location xlink:href="stylesheet.css"/> <xpackage:contentType>text/css</xpackage:contentType> </xpackage:resource> <xpackage:resource rdf:about="urn:oeb:samplepackage1-image1"> <xpackage:location xlink:href="image1.png"/> <xpackage:contentType>image/png</xpackage:contentType> </xpackage:resource>
RDF makes extensions so straightforward that any third-party resource or property can be used. As long as the rules of RDF+XML are followed, extensions will not destroy the consistency of XPackage and will still allow a generic RDF+XML processor to recognize that such an addition is truly a resource or property. XPackage in fact comes standard with its own extensions especially for XML-based resources, including the property this entire evolution has anticipated:
<xmlprop:style>Associating the above stylesheet with the above "chapter1" is as simple as adding the XPackage <xmlprop:style> property to the description of the "chapter1" resource, just as one would add any third-party extension:
<xpackage:resource rdf:about="urn:oeb:samplepackage1-chapter1"> <xpackage:location xlink:href="chapter1.html"/> <xpackage:contentType>text/html</xpackage:contentType> <xmlprop:style rdf:resource="urn:oeb:samplepackage1-stylesheet"/> </xpackage:resource> <xpackage:resource rdf:about="urn:oeb:samplepackage1-stylesheet"> <xpackage:location xlink:href="stylesheet.css"/> <xpackage:contentType>text/css</xpackage:contentType> </xpackage:resource>
The rdf:resource attribute references the unique identifying URI of the stylesheet resource, which is specified by the rdf:about attribute— much the same way as XML references elements use IDREFs and IDs. Any RDF+XML processor will already know this. The W3C's [W3C RDF Validator] will immediately recognize that the chapter has a given stylesheet, even though it might not know what a stylesheet is.
XPackage is the eventual offspring of a long line of specifications, the great-grandchild with numerous older siblings who, upon entering the real world, decided to attend to a certain corner for a precise period of time. XPackage, in its quest for universal applicability, was conceived on open, international Internet specifications. XPackage is an ontology of RDF. RDF uses XML for its serialization. XML uses Unicode as its code point set. Each specification builds on the other to find stability, consistency, and universality.
If XPackage is RDF, then does one need to intimately know that Resource Definition Framework, with all its triples, its serialization variations, the knights and castles of a thousand parallel ontological lands? The answer immediately comes back: no! and then, after a pause, a slight averting of the eyes, and an almost imperceptible sigh, comes the less forceful but decidedly surer: not really. Just use the XPackage XML Schema.
Once the academics have been politely escorted from the room, the window shades raised, and the radio station changed to something a little more upbeat, the fundamental concepts of RDF are straightforward:
If the world were nothing but concepts (and who is to say it isn't), things would be simple indeed. What makes things complicated is communication—how does one formally describe those resources, properties, and values? (The remaining academic, having betrayed her disguise through the use of the word "formally", sadly makes her exit and the forbidden word is striken from the record.) RDF describes a serialization, a set of instructions for talking about resources, properties, and values using the language of XML. XPackage uses RDF+XML to communicate package-related descriptions.
RDF+XML serialization is a bit eccentric at times, though, saying, "Do it this way," and then, "well, except here, but there's a very good reason why," and finally, "but we can't do that there—there's a logical answer, but now that there are no academics around..." XPackage supports RDF in all its slightly-crazed variations. XPackage using pure RDF is referred to as a package description instance.
For those who have grown attached to their sanity, XPackage allows the use of a package description document, an XML document that uses a RDF serialization according to a restricted set of rules. XPackage provides an XML Schema for a package description document, so that as long as the XML Schema is followed, the document will be guaranteed 100% correct RDF. No knowledge of RDF is needed. Not really.
The package description document framework is simple: it contains a couple of wrapper elements that mark the XML as an XPackage package description document and identify the contents as RDF:
<?xml version="1.0"?> <xpackage:description xmlns:xpackage="http://xpackage.org/namespaces/xpackage/2002/" xmlns:xmlprop="http://xpackage.org/namespaces/package/xml-properties/2002/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xlink="http://www.w3.org/1999/xlink"> <rdf:RDF> (description of individual resources go here) </rdf:RDF> </xpackage:description>
Inside those two elements, the relevant resources will be listed, each described by an XML element. XPackage provides several choices:
<xpackage:resource><xpackage:package>Each resource must be identified by some unique URI, although that URI need not actually "point" to anything. A simple package description document could be created to describe an HTML document, a stylesheet, and an image:
<?xml version="1.0"?> <xpackage:description xmlns:xpackage="http://xpackage.org/namespaces/xpackage/2002/" xmlns:xmlprop="http://xpackage.org/namespaces/package/xml-properties/2002/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xlink="http://www.w3.org/1999/xlink"> <rdf:RDF> <xpackage:resource rdf:about="urn:examples:mydocument"> </xpackage:resource> <xpackage:resource rdf:about="urn:examples:mystylesheet"> </xpackage:resource> <xpackage:resource rdf:about="urn:examples:myimage"> </xpackage:resource> </rdf:RDF> </xpackage:description>
Is is XPackage correct so far? Yes. How do we know? We validate it against the XPackage schema.
The package is thus far uninteresting, as we know nothing about the resources themselves—our resources descriptions are not very descriptive. What's needed are some properties, and again, XPackage gives us several from which to choose:
<xpackage:contentType><xpackage:location><xprop:style>Our ongoing XPackage example then becomes:
<?xml version="1.0"?> <xpackage:description xmlns:xpackage="http://xpackage.org/namespaces/xpackage/2002/" xmlns:xmlprop="http://xpackage.org/namespaces/package/xml-properties/2002/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xlink="http://www.w3.org/1999/xlink"> <rdf:RDF> <xpackage:resource rdf:about="urn:examples:mydocument"> <xpackage:contentType>text/html</xpackage:contentType> <xpackage:location xlink:href="doc.html"/> <xmlprop:style rdf:resource="urn:examples:mystylesheet"/> </xpackage:resource> <xpackage:resource rdf:about="urn:examples:mystylesheet"> <xpackage:contentType>text/css</xpackage:contentType> <xpackage:location xlink:href="stylesheet.css"/> </xpackage:resource> <xpackage:resource rdf:about="urn:examples:myimage"> <xpackage:contentType>image/png</xpackage:contentType> <xpackage:location xlink:href="picture.png"/> </xpackage:resource> </rdf:RDF> </xpackage:description>
Look closely: each of our newest additions describe properties of the resources, but each property takes values of different forms. The most straightforward is <xpackage:contentType>, which has a literal string for a value. (A literal string is about the only thing in RDF that is not a resource.) What could be simpler? The document with ID "urn:examples:mydocument" has a MIME type of "text/html". The other two resources have MIME content types of "text/css" and "image/png".
If you ever doubted that the value of rdf:about is merely an identification, not a location, the next property should remove all unsureties: <xpackage:location>. Instead of a literal string value, this property has an attribute named xlink:href. Is this an arbitrary attribute addition of the kind XPackage was supposed to remove forever?
The open shades have brought in the sunlight, and in an effort to let in the soft spring air someone has raised the window as well. One of the once-silenced sages in love with the more arcane aspects of RDF has remained outside and fallen asleep to the sounds of chirping birds and the scent of post-winter daisies. At the mention of arbitrary attributes, he starts; raising himself to the window frame he blurts, "It's not arbitrary at all, but it follows the rules of RDF+XML serialization. What is shown is a property that has as its value an anonymous resource, and one of its properties is xlink:href, which takes a literal string value. As he gasps a final, "and it's even compatible with XLink", someone wisely returns the window to its closed position, preferring a slight warmth to a stifling lecture.
Now, where were we? Is this an arbitrary attribute addition? Not at all—RDF, if it had feelings, would like this serialization very much. But XPackage doesn't need you to understand why. Just follow the schema. And yes, it is compatible with XLink.
The last property so far in our example is <xprop:style>, the specifier of stylesheets, the impetus of packing specifications, the purpose of this story in advance of its telling. Instead of taking a literal string value, this property specifies that another resource contains style information. That other resource is identified using the rdf:resource attribute. In this case, the resource identified by "urn:examples:mystylesheet" contains the style information for the resource identified by "urn:examples:mydocument". In purely human terms, mydocument has a stylesheet of mystylesheet.
Three resources are described by three types of properties. These resources and properties are described in an XPackage package description document. But where is the packaging information? If some application wanted to bundle mydocument in, for example, a Zip file [ZIP], what resources should go along with it? Such bundling information is the purpose of one more property, <xpackage:manifest>. The <xpackage:manifest> property lists all the files that relate to a resource and must, should the need for bundling arise, be included in whatever archive is generated. Our final package description document now becomes:
<?xml version="1.0"?> <xpackage:description xmlns:xpackage="http://xpackage.org/namespaces/xpackage/2002/" xmlns:xmlprop="http://xpackage.org/namespaces/package/xml-properties/2002/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:xlink="http://www.w3.org/1999/xlink"> <rdf:RDF> <xpackage:resource rdf:about="urn:examples:mydocument"> <xpackage:contentType>text/html</xpackage:contentType> <xpackage:location xlink:href="doc.html"/> <xmlprop:style rdf:resource="urn:examples:mystylesheet"/> <xpackage:manifest> <rdf:Bag> <rdf:li rdf:resource="urn:examples:mystylesheet"/> <rdf:li rdf:resource="urn:examples:myimage"/> </rdf:Bag> </xpackage:manifest> </xpackage:resource> <xpackage:resource rdf:about="urn:examples:mystylesheet"> <xpackage:contentType>text/css</xpackage:contentType> <xpackage:location xlink:href="stylesheet.css"/> </xpackage:resource> <xpackage:resource rdf:about="urn:examples:myimage"> <xpackage:contentType>image/png</xpackage:contentType> <xpackage:location xlink:href="picture.png"/> </xpackage:resource> </rdf:RDF> </xpackage:description>
The resource describing the HTML document now contains a manifest property, the value of which is a <rdf:Bag>. Why? It doesn't matter for now—just follow the XML Schema. That <rdf:Bag> contains a <rdf:li> list item for every resource that must be bundled with the HTML document. Again, the resourse to be bundled is specified in the rdf:resource attribute. And again in human terms, mydocument needs to take mystylesheet and myimage along with it, wherever it goes. Such is the purpose of the <xpackage:manifest> property.
But why this particular structure? Might RDF give some insights into this serialization? Yes, without a doubt. A little knowledge of RDF would also allow one to create specialized XPackage extensions. Much RDF knowledge would allow the creation of package description instances that used other XML schemas altogether. But for general use of XPackage, that knowledge is not required. Not really. Just use the XPackage XML Schema.
To see the power of relying on this this blissful ignorance, copy the entire example above, browse to the W3C's RDF Validator at http://www.w3.org/RDF/Validator/ [W3C RDF Validator] and paste the example into the the form. By selecting "Parse RDF", the W3C's RDF validator will create a graph of the RDF package structure, even though it had no knowledge of XPackage. Remarkably, this XPackage example was constructed, not from the viewpoint of RDF, but simply by following the XPackage XML schema. The XPackage example we've just created can be completely integrated with other RDF-based ontologies, such as the Dublin Core metadata [DC], annotations [Annotea], and the Semantic Web [W3C Semantic Web].
The need for a general, robust packaging specification is not new, but it's stronger now than ever. XPackage is not the first packaging specification, but it was created to be the basis for the last—as long as XML is used, anyway.
Other specifications that deal with packaging are relevant. The IMS Global Consortium is using its packaging specification [IMS Content Packaging] for describing questions and tests. The International Organization for Standardization (ISO/IEC) will be promoting its "MPEG-21 Digital Item Declaration" [DIDL] for describing multimedia objects. Both of these specifications are general enough to be used in a variety of situations, and are supported by more than a few shareholders, but their universal applicability and leveraging of existing standards are still unclear.
XPackage was not even the first specification to build a packaging framework upon the semantically robust RDF, although its similarities to another specification were unknown at its creation. In 1999, while OEB and IMS were making their constrained excursions into packaging frameworks, Netscape created a framework for describing channels and gathering content for the My Netscape Network [MNN]. Over time this Rich Site Summary format served as the basis for RSS 1.0, an "XML-based lightweight multipurpose extensible metadata description and syndication format" [RSS].
The central object in an RSS document is a channel which can group other resources in a given sequence. Like XPackage, RSS documents are compliant with RDF. Modules can be added that provide domain-specific metadata, such as the Dublin Core or some other ontology. RSS even provides a restricted syntax, allowing RSS to be created and consumed without RDF awareness.
RSS does not follow the latest RDF syntax recommendations, however, and furthermore does not disinguish between resource identifiers and resource locations. No RSS modules have yet been created that describe XML-specific properties, such as namespace, document types, or the impetus of this journey: stylesheets. The technical bases of XPackage and RSS are very similar, yet explicit packaging support in RSS is currently immature. How XPackage and RSS will continue to grow (now that they are each aware of the other's existence) remains to be seen.
XPackage seeks to create a framework for package descriptions that is not particular to any application but is amenable to all packaging needs. Its strength lies in its consistency, applicability, and adherence to standards such as RDF and XLink. Its simplicity ("just follow the XPackage XML Schema"), consistency, and extensibility ("like XML, only the extensions are consistent") provide a stable, familiar base that looks to the future. XPackage is surely packaging with style.