Since we are talking about trying to get as many people involved in
the documentation process as possible, it should be as
straightforward as possible for Pd people to do it. If each chunk of
meta data is a Pd selector series, where the selector defines the
type of meta data, and the rest is the data, then we have an easy to
understand and parse format.
For example: [keywords sound oscillator( would be a useful chunk of
meta data for [osc~]. This format could easily be parsed in Pd
itself using no externals (unlike XML), and it is also easy to parse
it with perl, python, etc. to generate XML, or whatever.
.hc
On Feb 9, 2007, at 1:16 AM, padawan12 wrote:
Yes. At the risk of building a whole content management system (is puredatabase still built on Zope/Plone?) this seems the sensible
format. At some point I would like to move some tutorials I've made onto
the system. These are mainly HTML with diagrams and links to patches and
sounds. A really thorough system would allow this and make it easy.But, from a development POV might I suggest that this is ambitious
and one would be best to concentrate on just getting it to work right
with .pd files to begin with, then add the bells and whistles to allow richer
content. But being mindful of future content types cant hurt.One interesting and challenging enough problem that already exists
is how to make sure that help/tutorial/exmaple patches that depend on certain abstractions and externals will always load.This is a dependency issue not dissimilar to the pakage management
needed in something like the Debian apt repository system. It may be possible to tag each resource with its minimum version and libraries needed,
or it might be better to hold multiple verions of the same resource and
be able to browse by platform and current Pd version.The way I see it, Puredatabase is not just there to organise and
structure documentation, it is there to make maintainance as easy as
possible. We have an ongoing struggle to keep helpfiles up to date. One of the views,
for maintainers, should reflect those needs. It should be easy enough
to use so that anyone who spots an error or omission can quickly log in
and make changes Wiki style.Hope I'm not just prattling on about issues you've already considered.
On Thu, 08 Feb 2007 10:05:10 -0500 marius schebella marius.schebella@gmail.com wrote:
Hans-Christoph Steiner wrote:
I thought we (the potential users of the database) in this phase
could brainstorm and discuss ideas on how we would like it.I think this should be generated from the meta data in the help
files. For PDDP, we plan on using the help files as the central location
for meta data.I would rather have content (in xml style) and layout (webformat, pdf format,...) separated
<object> <objectname>coolobject</objectname> <library>core</library> <description>blablablab</description> <tags>audio,streaming,web,keywords<tags-family> <help-patch> a pd patch... </help-patch> </object> (...and many many more). parsing this meta data into the pd patches is probably easier. and editing the metadata outside, too. (using copy, paste, replace) m.
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
Terrorism is not an enemy. It cannot be defeated. It's a tactic.
It's about as sensible to say we declare war on night attacks and
expect we're going to win that war. We're not going to win the war
on terrorism. - retired U.S. Army general, William Odom