Roland,
> As it seems to be very easy to make mistakes with "redefine",
> probably to have types named differently on a per element
> base is more save.
>
> Though it looks (!) a bit odd to have 15 types defining the
> same content model in the base scheme - the reason one
> perhaps should explain shortly in the base scheme.
>
> Maybe one could name these gadgets creatorContent and the
> like, rather than creatorType
> - not to overload "Type" with too many different meanings.
> (dc:type, xsd:type, xsi:type, rdf:type).
Hmmm, yes, maybe it is better to avoid a convention which involves a
complexType called (gulp) "typeType"... even if it has a certain
relentless logic to it.... ;-)
> Here it is really about
> the content model(s) [in the sense of xml] of the DC-elements
> implemented as elements [in the sense of xml].
Yes.... On this basis how about naming the types "titleModel",
"creatorModel" etc. Strictly speaking, I think they address slightly
more than "element content" in so far as they describe permitted
attributes too.
But even with these one-per-element types/models I'm still not sure how
to achieve the sort of application-specific "tightening" of the content
model which Carl suggested though. e.g. if an app wants to tighten its
own content model for dc:date so that it validates as a date rather than
only to the loose base model, or if OAI wants all element content to be
strings....
I was thinking along the lines
<xs:redefine
schemaLocation="http://www.ukoln.ac.uk/metadata/dcmi/dcxml/xmls/simpledc
20020306.xsd">
<xs:complexType name="dateModel">
<xs:complexContent>
<xs:restriction base="dateModel">
<xs:sequence>
[but what goes here to "tighten" the model so that it validates as a
date instead of as "text"?]
</xs:sequence>
<xs:attribute ref="x:lang"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:redefine>
I just can't see how to make this work so I think a different approach
is required.... But I'm not quite sure what.
> Minor point: Is it meaningful to have maxOccurs="unbounded"
> inside (!) a choice element? Think the expected behaviour
> doesn't change when including the group without the internal
> "unbounded" - or?
I think you're right... It looks like the internal maxOccurs and
minOccurs (i.e. the attributes on each xs:element element) are
redundant.
Actually looking back at Jeni Tennison's message, she had removed them,
so it was my mistake retaining them.
I'll remove them in simpledc20020306.xsd
Thanks
Pete
|