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 <[EMAIL PROTECTED]> 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.
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/
listinfo/pd-list
_______________________________________________
[email protected] 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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
