> From [log in to unmask] Wed Mar 6 14:24 MET 2002
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
> Importance: Normal
> Date: Wed, 6 Mar 2002 13:25:24 -0000
> From: Pete Johnston <[log in to unmask]>
> Subject: Re: Public Comment on DC-simple XML Schema declaration within OAI
> To: [log in to unmask]
>
> Carl, Jane,
>
> > I agree with Jane's idea of a broader base type; just not in
> > touch with how to implement it and then getting lost in some
> > really messy territory.
>
> > Jane, I've seen some code fragments suggesting how to do
> > this. Perhaps we can develop a complete example....
> >
> > xml for the "base schema" defining the elements with a proper
> > base type
>
> OK, I've put up another version
>
> http://www.ukoln.ac.uk/metadata/dcmi/dcxml/xmls/simpledc20020306.xsd
>
> which uses the model for the text type from the XML Schema Primer as the
> basis for the "base" elementType. (XML Spy reported validation errors on
> importing the type library.... Easier to put the full type definition
> here for now.)
>
> I've validated examples against this with XML Spy and XSV. That might be
> usable as your "base schema"?
>
> > packaging schema with types restricted by a community (e.g.,
> > OAI who only wants string values)
>
> Would this involve some use of xs:redefine in this "packaging schema"?
> My understanding of redefine is that you modify the simple/complex types
> on which elements are based - so it may require the introduction of
> element-specific types (e.g. titleType, creatorType etc etc) in the
> simpledc schema in order to give that packaging schema something to work
> with?
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).
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].
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?
rs
>
> Pete
>
|