> Certainly that's a starting point; however, the Rebol header block is
> extensible, not mandatory, and not really typed in any way. My first thought
> is a func in a well-known .r file that mandates certain metadata that would
> be understood by the engine, and that would send it to the engine and
> publish it.
>
> K.
Hi Kemp,
Do you mean something like :
REBOL [
File: %index.r
Description: "Rebsite index with MetaData in block header"
Author: [EMAIL PROTECTED]
Date: 2002-09-08
Metadata: [--keywords and sub-blocks here--]
Engine: %rebsites.net/engine.r
]
...Where the engine.r would be a sort of rebolistic version if XML-DTD but a lot
nicer :-)
And the Metadata: block in the header would be picked up by any interested
service.
The remote service would have the choice to use its own engine and/or load or
compare against the one defined in the script header block. Something to allow
easy convergence or divergence as application or access demands.
Then at a minimum engine.r might check for a basic metadata block. A small
script or View/app could be run to invoke the engine check that files and help
people to quickly accurately add/edit their metadata fields without having to
remember detailed syntax or get too low down..
The engine.r loaded in the desktop app might also check for obvious conflicts
between a local engine and a remote one... [which could lead us to the hairy
topic of topic maps]
The key point being a reasonable separation of content and tool, but exploiting
REBOL lovely way of fusing them ;-)
hope I am making sense here..
./Jason
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
