site_archiver@lists.apple.com Delivered-To: installer-dev@lists.apple.com On Oct 4, 2008, at 3:27 PM, Bill Coderre wrote: Why not document the formats of installer PACKAGES themselves? 1) Installer packages are much less buggy 2) They are a lot more likely to be supported in a few years... Philip Aker echo astwta@lvpc.dslh@nl | tr a-z@. p-za-o.@ Democracy: Two wolves and a sheep voting on lunch. _______________________________________________ Do not post admin requests to the list. They will be ignored. Installer-dev mailing list (Installer-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/installer-dev/site_archiver%40lists.a... I'd love to have a publicly available spec for this... The official answer will probably be that you can file a bug report on this requesting the format to be made available publicly. I will save you some time: I filed a enhancement request for that more than 3 years ago regarding the format of PackageMaker documents. I think the answer at one point was something equivalent to: which word don't you understand in 'proprietary format'? So your best option is to document it yourself. Seriously, a bundle package contains a pretty small number of things to document, and it's easily constructed using common unix tools. Sheesh, mkbom even has a pretty good man page... I recommend moving to the professional level of an XML Schema description <http://www.w3.org/TR/xmlschema-1/> for describing package formats since it is the international standard. This would bring the benefit of stability for both users and developers since the validation features can help to locate bugs before they make it into release versions while the structural description can provide a means to interface the format with tools, applications, and documentation facilities easily. In addition it has versioning capabilities so it can handle future needs without the development team having to get their shorts tied in a knot at every upgrade (or suffer the barbs of this list!). You are right that packages don't have a large number of components. Compared to the needs of CSISC <http://www.cdisc.org/models/odm/v1.3/index.html
or the Data Standards Secretariat <http://www.dss-snd.gc.ca/public_MainPage_e.htm [1] what is being dealt here with seems absolutely puny. Yet these organizations deal effectively with complex documents in multiple output formats using multiple tool/application interfaces (on multiple platforms). That is the power of XML Schema.
[1] Various documents including taxonomy and element descriptions available after you sign a download agreement. This email sent to site_archiver@lists.apple.com