Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <47A813C9.3000502@submerged-intelligence.de>
Date: Tue, 05 Feb 2008 08:44:09 +0100
From: Fabian Haupt <kazamatzuri@submerged-intelligence.de>
User-Agent: Thunderbird 2.0.0.9 (X11/20080127)
MIME-Version: 1.0
To: jspwiki-dev@incubator.apache.org
Subject: Re: Metadata in 3.0 [Was: JSPWiki 3 design notes]
References: <D33B3461-FFD5-4DAD-BFB0-BD5D881B0CFB@ecyrd.com>
 <47A78EF4.4000108@altheim.com>
In-Reply-To: <47A78EF4.4000108@altheim.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+1

Hi,

I'd really like that approach. That way it would be easy to add( and
possibly edit) picture's metadata given in the various formats from
within the wiki. Using this one could easily implement, something like a
'picture management wiki', like for collaborative tagging of holiday
pictures with you pals.

greets
Fabian


Murray Altheim wrote:
| In looking at the 3.0 design document at
|
|    http://www.jspwiki.org/wiki/JSPWiki3Design
|
| I have some comments on the metadata plans. These comments are only
| tentative.
|
| ----
| ! Metadata Meta API
|
| Now, before getting into this too deeply it occurs to me that we might
| consider a pluggable meta API rather than single metadata schema. There
| are likely a variety of different applications that JSPWiki may be
| used within (simple wikis, embedded apps, hives, part of document mgmt
| systems, etc.), and we likely also want scalability (i.e., in terms of
| both simplicity/complexity and factors like page an revision count) in
| our metadata just as we do in other areas. I don't think this sounds
| particularly difficult if we're using a JSR-170 compliant repository:
| there'd be a core set of metadata fields whose actual descriptors would
| be assigned by the API implementation. If an application needed more
| than that it'd be up to the implementation to define and handle (e.g.,
| because the documents will be used within a more complex framework or
| document management system having an existing schema). We'd simply be
| creating the API and reference implementation.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHqBPJtC//DIQj2V8RAjoGAKCg+LCsTRc8VnGMvghNYR1HjrReRgCfVAv8
6ymmoWJV5B2SpcP+FzMFZxE=
=gX1L
-----END PGP SIGNATURE-----