Print

Print


>>> [log in to unmask] 05-08-2005 1:26 >>>
>Oooooo-kay.  That is pretty lame, but I have to admit that it does
>just about manage to limp along.  OK, I won't complain about the
"rec"
>schema any more (though it would be good to see this use-case in the
>schema documentation).
>
>... but how much better to have a schema that lets you include the
>record-level metadata along with the data.

We need one big schema that defines only the terms from different
schema's (dc, rec etc.) without specifying the actual root and structure
of the metadata record. This will allow applications to refer to all the
different variants of DC by means of single schema name. Most
applications will be capable of ignoring the terms that they do not
know. The advantage is that applications do not have to know the many
different schema's that all have DC as a kernel. If we can say it has DC
and rec and a few others as a kernel it is even better.
We (KB) use the name DCX  as a generic name for this.  The name and id
should remain the same even if the underlying schema is extended. For
local validation purposes ofcourse a second  "real" schema should be
available but that only needs to be known locally.

Let me reserve "info:srw/schema/3/dcx" for that generic schema.

I have no experience with writing schema's but I assume the main part
of the schema will look like this:

  <xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/03/xml.xsd" />
  <xs:import namespace="http://purl.org/dc/elements/1.1/"
schemaLocation="dc.xsd" />
  <xs:import namespace="http://purl.org/dc/dcmitype/"
schemaLocation="dcmitype.xsd" />
  <xs:import namespace="info:srw/schema/2/rec-1.0"
schemaLocation="http://srw.cheshire3.org/schemas/rec/1.0/rec.xsd" />
  <xs:any namespace="##any" processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>


Theo