What I had in mind when I introduced the schema DCX (as text rather than
an XML schema) was that it was just a second name for existing schema's.
Suppose someone has a schema that contains mainly DC elements and a few
more extra elements, he can use that schema for validation at the time
of creation of those records. However, external applications won't know
that it is mainly DC. Therefore he can make external applications aware
of the fact that there is a "mainly DC" schema by adding DCX as an
additional available record schema in SRU explain and OAI-identify.
Applications that support DCX shouldn't bother about the name of the
root element. We use srw_dc:dc but oai_dc and others might also be used
as root element or wrapper.
The DCX schema only has to express that the actual records contain
enough DC elements to be useful for applications that can only use the
DC elements. I don't know if that can be expressed in an XML-schema.
Van: SRU (Search and Retrieve Via URL) Implementors [mailto:[log in to unmask]]
Namens Ray Denenberg, Library of Congress
Verzonden: dinsdag 15 april 2008 20:48
Aan: [log in to unmask]
Onderwerp: the "dcxyz" schema
Further to the discussion of a format where dc elements may be mixed
elements from other namespaces .....
I have drafted a schema which I'll call, temporarily (pending discussion
its name), dcxyz.
Here is a hypothetical instance:
- Even before considering the namespace enhancement, this differs
significantly from the SRU dc schema, which (1) provides for both dc
and dc collection, and (2) handles namespacing completely different, so
dc elements are not prefixed. This schema does neither, and I am
that nobody want either of these features; let me know otherwise.
- This schema requires wrappers <dcElements> and <otherElements>.
defining these, the schema won't validate because the content model is
ambiguous, due to the introduction of arbitrary namespaces.)
- The schema element <xs:any> allows you to include any namespaced
and have it validated against a schema, or not.
It uses processContents="lax", which means that you can include a
location or not for any given namespaced element. If you do, it will
validate; if you don't it won't. In the example schema non-dc elements
included from MODS and from prism. The MODS element is validated
the MODS schema location is included. The prism elements are not
because no schema location is provided.
Functionally this is essentially the dcx schema we've been discussing
propose that we formalize it as dcx. Since some form of a dcx schema
apparently is in use, I will call it something else if there is
Since there is currently no formal definition of dcx, I don't know for
if dcx that has been implemented conflicts with this definition. If it
does we can either try to resove the difference or give this schema a
different name. In either case this would be the official LC
schema for mixing dc simple element with elements from other namespaces.
This schema is only a draft at this point so comments are welcome, but I
don't see a need to prolong this process, it's not really as complicated
we're making it, so if you want to comment please do so soon.