Minutes of 19991207 XML Packaging Task Force meeting

Recorded by Paul Grosso

copied from earlier location

Contents

Attendees

Administrivia

This meeting was requested by the XML CG and announced on the XML Plenary mailing list. We met in Philadelphia in conjunction with the XML'99/Markup Technologies'99 conferences. The stated purpose of the meeting was to initiate "an hoc task force of volunteers from the XML plenary whose job is to draft a charter to be proposed to the CG for an XML Packaging Working Group."

Paula Angerstein chaired this meeting; Paul Grosso took notes.

Background material

Some relevant documents:

Discussion

The XML Packaging WG has an approved charter. This TF meeting is to consider the range of related issues/use cases, re-evaluate the charter in light of these issues, and make suggestions to the CG about how best to address the issues. Possible outputs include a revised charter for the XML Packaging WG, suggested work items for other existing WG's, and suggestions for other potential WGs.

Use cases

  1. A package as the machine-processable thing that a namespace URI points to
  2. One-shot transmission (e.g. email) of an XML document, external entities, DTD/Schema, Style Sheet, java scripts, etc.
  3. Archiving a collection consisting of an XML document, external entities, DTD/Schema, Style Sheet, java scripts, etc.
  4. A "manifest" containing pointers to an XML document, external entities, DTD/Schema, stylesheet, java scripts, etc.
  5. Transmission of fragments, where fragments can be:
    • fragment per XML Fragment PR (XML parsed entity)
    • set of fragments, e.g., a set of query results
    • incremental update information (aka change package)
  6. A package as a message with a header and a body, e.g., an ICE payload, a BizTalk document
  7. A package as a document and associated metadata (how do you associate RDF statements with the XML document it describes)
  8. Exchanging a subtree of a file system, i.e., maintaining relative file paths through transmission
  9. Digital signatures, encryption
  10. Compression. Support for streaming news feeds where all components of the package cannot be resolved up front.
  11. Class-based packages as opposed to instance-based.
  12. Versioning of instances, schemas, etc.
  13. Metadata about the package itself (including WAI-related info).
  14. Indexing into a package.
  15. Streaming packages.
  16. Fallbacks (specifying alternate resources to use depending on context/output device/etc.).

Discussion

Joseph: must be able to sign a package, because how a document is rendered (via a stylesheet) may be important. Sometimes reference things or make local copies of things versus actually delivering the master copy of the thing. Don't want to arbitrarily mess with things in the package.

Noah: can you use a package to define a namespace and/or class of documents (as opposed to only defining a single document).

Ashok: versioning of instances, schemas, etc. Packaging of SVG and other graphics and binary data.

Daniel: using packaging as a cache. Packaging software distributions. Metadata about components and metadata about the package itself.

Marc: need to remember network constraints--packaging isn't always monolithic.

Daniel: a package is a resource.

Murray: the package metadata could identify WAI features.

SteveZ: getting one component out of the package without unpacking the entire package.

Daniel: identifying one component of a package as special, i.e., the "root" of a package; indexing.

SteveS: not having to download the whole package before unpacking part of it--streaming.

SteveZ: can a package be a component of a package?

Christina: metadata in package that includes contractual constraints on the information in the package. Need an index to randomly access the package. EDI packages may consists of multiple messages. May want to send fragments rather than whole documents; graphics may be associated with specific fragments. May need to package business metadata into a package in the case of archiving. Packages need to be able to reference resources as well as contain resources.

SteveS: incremental generation and consumption of packages to support streaming. Need for intra-package references.

Marc: being able to treat a package on a file system in a similar way to a package being transmitted.

Joseph: part of metadata about the package might include a URL mapping capability (e.g., to allow one to substitute a local copy of a resource).

Tim: Just addressing use cases 1, 2, and 4 would hit our 80/20 point, be buildable out of existing technology, and doable in a reasonable time frame. [Tim also elaborated on the theme of his paper that a namespace URI could point to a package of pointers to interesting things associated with this namespace.]

Dan: use case of asking for an invoice and then getting as a response an invoice plus other stuff in a package. One needs to be able to identify the invoice, so that something that only expected an invoice back can find that and ignore the rest.

Noah: Dan's case might happen in the case of layered protocols, e.g., one layer cares about the signature and another layer cares about the thing that is signed.

Ben: a fallback concept might be useful in a package, so that a single package could include multiple things to be used depending on the target output device or so.

Jon: EDXML meeting included a meeting of some XML messaging and packaging group. IETF gets in here somewhere that I couldn't understand. Jon has a draft he will circulate to us soon. Maybe we should hold off some of our work--or redirect our work--in light of this work.

Didier: business data flow where each node is adding to the package or is putting packages within packages.

Peter: three levels of packages: logical level structure, physical level container, third level incremental creation and transmission.

This task force will communicate using the following email list: w3c-xml-pkg-tf@w3.org; everyone at this meeting plus others who have already sent the TF chair an expression of interest will be put on the initial list.