Re: Adding tags to xsd:documentation

Hi Dan,

> MSV gives me an error/warning about attributes that appear on some of the
> elements that I have added, but not the elements.
>
> unexpected attribute "adoc:ref"
>    19259:110@file:///C:/xml/Xerces/acord-pc-v1.1.0-fulldoc-nocodes-draft-6-5.xsd
> unexpected attribute "xml:space"
>    19265:41@file:///C:/xml/Xerces/acord-pc-v1.1.0-fulldoc-nocodes-draft-6-5.xsd

That's peculiar -- I don't understand why MSV would complain about the
attributes but not complain about lacking a declaration for the
elements. I'd suspect a bug; certainly it shouldn't be complaining
about attributes on those elements (unless, of course, you're
validating the schema against a schema-for-schema in which there's
strict validation of the element content of xs:documentation).

> Xerces gives me similar errors.
>
> [Error] acord-pc-v1.1.0-fulldoc-nocodes-draft-6-5.xsd:3452:68: 
> s4s-elt-must-match: The content of 'group (local)' must match (annotation?).
> [Error] acord-pc-v1.1.0-fulldoc-nocodes-draft-6-5.xsd:3499:68: 
> s4s-elt-must-match: The content of 'group (local)' must match (annotation?).
>
> In the case of Xerces it seems to limit its error reporting to the
> use of the annotation tag within a reference to a group, all other
> uses of the same construct in element and data type definitions seem
> to pass.

This is a strange error to be getting unless there is something wrong
with how you're using group references within your schema. It seems to
be complaining about you having content within an xs:group within a
content model (a local group) *other than* xs:annotation -- at least
that's what the error message says. Without seeing the relevant part
of the schema it's hard to tell what's going wrong.

> First for a Schema spec standpoint, should the following be allowed:
>
>        <xsd:annotation>
>           <xsd:documentation>
>              <p>This aggregate is used to send requested coverage and 
> insured values as part of a Commercial Property Schedule submission.</p>
>           </xsd:documentation>
>           <xsd:appinfo>
>              <tagType>Aggregate</tagType>
>              <service>Insurance</service>
>              <category>Commercial</category>
>              <tagtitle>Commercial Schedule Insured Value Aggregate</tagtitle>
>           </xsd:appinfo>

Yes.

> If so what sorts of import and redefine statements do I need to use?
>
> I saw a post from Jenni (Jan 14, 2002) that talked about using the
> schema-for-schema for something like this. She indicated that it was
> setup with lax validation - If I want the best and strict validation
> am I going to have to modify the schema-for-schema to accomplish
> this?

The way that the schema for schema is constructed, the easiest (in
fact, I think the only) way of changing the schema for schema so that
it carries out strict validation on the content of xs:annotation and
xs:documentation is to actually edit the schema itself. Copy the
version at http://www.w3.org/2001/XMLSchema.xsd and edit the two
element declarations so that the xs:any wildcards they contain have
processContent="strict" rather than processContents="lax":

<xs:element name="appinfo" id="appinfo">
 <xs:annotation>
  <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-appinfo" />
 </xs:annotation>
 <xs:complexType mixed="true">
  <xs:sequence minOccurs="0" maxOccurs="unbounded">
   <xs:any processContents="strict" namespace="##any"
           minOccurs="1" maxOccurs="1" />
  </xs:sequence>
  <xs:attribute name="source" type="xs:anyURI" /> 
 </xs:complexType>
</xs:element>

<xs:element name="documentation" id="documentation">
 <xs:annotation>
  <xs:documentation source="http://www.w3.org/TR/xmlschema-1/#element-documentation" /> 
 </xs:annotation>
 <xs:complexType mixed="true">
  <xs:sequence minOccurs="0" maxOccurs="unbounded">
   <xs:any processContents="strict" namespace="##any"
           minOccurs="1" maxOccurs="1" />
  </xs:sequence>
  <xs:attribute name="source" type="xs:anyURI" />
  <xs:attribute ref="xml:lang" /> 
 </xs:complexType>
</xs:element>

You could also change the namespace attribute on the xs:any wildcards
so that they point to the namespace of the elements that you want to
use within your schema.

You could even go the whole hog and edit the content model so that it
reflects the content that you'd like to see in the
documentation/appinfo elements. To do that, you'll also need to add an
xs:import to the schema-for-schema so that it imports your schema for
the elements that you want to be present.

The "proper" way to do this would be to write an "adapter" schema that
redefines the appropriate parts of the schema-for-schema while leaving
the rest untouched. Unfortunately, the only things that you can
redefine using XML Schema are type definitions and (attribute) group
definitions -- you can't redefine element declarations. Since the
complex types used by xs:appinfo and xs:documentation in the
schema-for-schema are anonymous, they can't be redefined, and they
don't contain a group, so you can't focus the redefinition onto the
content model. I've commented on this before [1]; I thought that the
schema-for-schema was going to be changed to make this easier, but
it doesn't seem to have been yet.

Note that even if you do change the schema-for-schema this will not
change the way in which validators check the schema that you use (or
at least I don't think that any of the validators support you pointing
to your own schema-for-schema?). You will have to have a separate
validation step, checking the schema against your amended
schema-for-schema, before you validate an instance document against
the schema.

Cheers,

Jeni

[1] http://lists.w3.org/Archives/Public/xmlschema-dev/2002Jan/0151.html

---
Jeni Tennison
http://www.jenitennison.com/

Received on Thursday, 4 July 2002 05:40:14 UTC