New core schema for review

["Scott Cantor" <cantor.2@osu.edu>]

Attached is a complete proposal on fixing the core schema to address various
problems identified with some of the existing type derivations. This schema
passes SQC checking, and validation of samples by Xerces-C/J and JEdit. I
will check further myself, but encourage broader validation.

There's a small tweak to the metadata schema that's trivial, but we can
discuss that separately and doesn't really need the same review.

This large proposal is as follows. It looks like a lot but actually isn't
changing much in terms of what's actually allowed and what's used by the
spec to express our current set of constructs. Mostly it just fixes the
schema and changes how extensions to BaseID might be done.

- creates an attribute group containing the NameQualifier and
SPNameQualifier string attributes.

- adds a new type called EncryptedElementType that contains the
EncryptedData and EncryptedKey sequence we use all over

- turns <BaseID> and BaseIDAbstractType into an abstract element containing
the name qualifier attribute group, along with an ##other anyAttribute
wildcard, but an empty content model. This permits extensions to define
element content for their own custom identifier approaches, along with XML
attributes, but does not permit simple content to be used in such
extensions. Can discuss reason for this on call (but you'll get a headache).

- turns <NameID> and the type into an extension of xsd:string that adds the
name qualifier attribute group plus the Format and SPProvidedID attributes
as now. Arbitrary attributes are no longer permitted in keeping with the
"must have use case" theme but could be added back.

- turns <EncryptedID> and the type into an extension of EncryptedElementType
that adds the name qualifier attribute group.

- bases <EncryptedAttribute> and <EncryptedAssertion> directly on the
EncryptedElementType since they have no other content, thus unifying the
type definitions for all encrypted "stuff" (something John Kemp suggested
which is now possible)

- redesigns <SubjectConfirmationData> and its type such that it derives from
anyType by restriction, which is the only way it can be done, defines the
common attributes I invented, and then explicitly permits anyAttribute and
<any> elements with mixed content, essentially providing an open content
model as before but with some facility to support extension types

- leaves KeyInfoConfirmationData as before, but I'm seeking clarification
that not repeating the attribute definitions from the base type is ok, which
doesn't fit my reading of the spec but seems to be how the tools work,
making me suspicious.

I would encourage all reviewers working on tools and code to plug this in
and experiment with it.

-- Scott

sstc-saml-schema-assertion-2.0.xsd