Williams, Timothy W. wrote:
Williams, Timothy W. wrote:
Nope, not with the XML:DB API (though this information is actually
stored in Xindice, or at lease I've been told it is). I'm
supposed to
come up with a generic metadata support, but I don't have a precide
timeframe for it. I could use some help... :-)
Have you settled on an approach to storing and accessing
metadata yet?
--tim
While I was still at Sun, I wrote a metadata wrapper for Xindice
called "XNode" which has been submitted to the project. It's very
similar to a lightweight SOAP, ie., it's got an envelope, header
and body. The Java Web Services Pack has a demo application called
"Indri" that implements the XNode API. I'm using XNode (and of
course Xindice) as the means of storing content and metadata in my
current project. The delivered API has three metadata attributes:
node ID, creation and modification dates.
In my admittedly ignorant understanding, it seems that if the wrapper had
it's own schema and the payload (body|resource|document?) had it's own
schema things would break. So if you were simply wrapping the metadata
around a whole resource that had a schema reference in it, it would generate
a parse error, no?
Only if you require that all content going into Xindice be valid XML,
as opposed to well-formed XML. If you validity, validate the source
document and strip off the DOCTYPE declaration (if your schema is a
DTD). If you're using RELAX or XML Schema there shouldn't be a problem
at all, since validation is via XML Namespaces and XNode (and all of
its elements and attributes) are in their own namespace.
Is there general agreement that simple key/value pairs like creation/mod
dates is enough or is there a requirement for nested heirarchical metadata?
I think you'll find there to be no "general agreement" since the need
for metadata in databases is so wide. The three existing metadata in
XNode are implemented as attributes on the <xnode:Header> element, with
extensions to this as element content. It's this latter feature that's
not in the XNode API I submitted to Tom and Kimbro last year, that I'm
currently fixing. I needed to add MIME type (or datatype) of the content,
and a way to store the DOCTYPE's public and system identifiers.
Is there general agreement that metadata will only be at the
document/resource level and that more granular metadata would need to be in
the document itself? I notice the project planning notes (#13) has "Node
level meta data". what's an example of "node level meta data"?
There's little reason to pollute a document with metadata if there's
a means of not doing so. It's simple to hook metadata content to a
specific node in a document either via ID or an XLink using XPath.
sorry for the simple questions, metadata is a fairly big topic with varying
definitions, so I wanted to make sure I'm talking about the same thing...
I quite agree, which is why I thought a general capability in Xindice
was needed.
Murray
......................................................................
Murray Altheim <mailto:m.altheim @ open.ac.uk>
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK
In the evening
The rice leaves in the garden
Rustle in the autumn wind
That blows through my reed hut. -- Minamoto no Tsunenobu
