copied from earlier location
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.
Some relevant documents:
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.
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:
at this meeting plus others who have already sent the TF chair an expression
of interest will be put on the initial list.