Roland,
> As far as i can see the only "complex" thing you use is the
> xml:lang attribute. What is the purpose to define a
> complexContent with no mark up allowed?
>
> One can do, but what good for?
There were differences of opinion in our "working group" on this issue
;-)
One consequence of using complexContent is that it allows applications
to derive complexTypes which do permit embedded markup, as Tom suggests
here:
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0209&L=dc-architecture&T=
0&F=&S=&P=1931
But leaving that aside, we probably came to the conclusion that this was
the best option available as a result of investigating various other
typing options.
I'll admit that I started off from a position that (rather as you
suggest) we needed a complexType but, if we were not permitting embedded
markup, we didn't need complexContent. A few months ago, I became quite
keen on an approach which used a default type based on xs:anySimpleType.
Something like:
<xs:complexType name="langAnySimple">
<xs:simpleContent>
<xs:extension base="xs:anySimpleType">
<xs:attribute ref="x:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="title" type="langAnySimple"/>
[etc]
which was first suggested by Jane:
http://www.jiscmail.ac.uk/cgi-bin/wa.exe?A2=ind0203&L=dc-architecture&F=
&S=&P=10574
We went quite a long way down this route, but eventually discovered that
although some parsers seemed to accept it, XML Schema does not permit
it:
http://lists.xml.org/archives/xml-dev/200206/msg00446.html
http://www.w3.org/2001/05/xmlschema-rec-comments#pfiS4SanySimpleType
I think some of this clarification was only finalised after we had
embarked on our work. Oh well, it was back to the drawing board....
So, the (rather subtle!) use of the dc:SimpleLiteral complexType,
suggested by Tom and Tim on the basis of their work at Illinois,
appeared to be the only option which allowed the derivation of
complexTypes with simpleContent to represent the encoding schemes,
permitting the use of built-in simpleTypes for validation.
> Schemes seem to be believed to force simpleContent model -
>
> http://www.dublincore.org/documents/2000/07/28/dcmi-period/
>
> is an example, that one might encounter XML mark up in scheme values -
I can't
> see how one should dumbdown such schemes to a base type, which doesn't
allow for
> mark up in the content model.
Yes, that is correct. The schemas as constructed do not support the
Period/Point/Box-in-XML convention, only the DCSV-based approach.
I think the complexTypes for Point/Period/Box could be altered to
support embedded markup, if required.
Pete
|