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. 

Theo


-----Oorspronkelijk bericht-----
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
with
elements from other namespaces .....

I have drafted a schema which I'll call, temporarily (pending discussion
of
its name),  dcxyz.
It's at:
http://www.loc.gov/standards/sru/resources/dcxyz.xsd

Here is a hypothetical instance:
------------------------------------------------------------------------
----
-------------------
<dcxyz
xmlns="info:xxx/yyy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="info:xxx/yyy
http://www.loc.gov/standards/sru/resources/dcxyz.xsd"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:prism="http://prismstandard.org/namespaces/1.2/basic/"
xmlns:mods="http://www.loc.gov/mods/v3">

<dcElements>
      <dc:contributor>Cat's Cradle</dcElements>

<otherElements>
    <mods:genre xsi:schemaLocation="http://www.loc.gov/mods/v3
mods-3-3.xsd">science fiction</mods:genre>
    <prism:startingPage>145</prism:startingPage>
    <prism:endingPage>160</prism:endingPage>
</otherElements>

</dcxyz>
________________________________________________________________________
_

Observations:

-  Even before considering the namespace enhancement, this differs
significantly from the SRU dc schema, which (1) provides for both dc
record
and dc collection, and (2) handles namespacing completely different, so
that
dc elements are not prefixed.  This schema does neither, and I am
assuming
that nobody want either of these features; let me know otherwise.

- This schema requires wrappers <dcElements> and <otherElements>.
(Without
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
element
and have it validated against a schema, or not.
It uses processContents="lax",  which means that you can include a
schema
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
are
included from MODS and from prism.  The MODS element is validated
because
the MODS schema location is included. The prism elements are not
validated
because no schema location is provided.


Functionally this is essentially the dcx schema we've been discussing
and I
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
objection.

Since there is currently no formal definition of dcx, I don't know for
sure
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
maintained
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
as
we're making it, so if you want to comment please do so soon.

--Ray