Re: Make an required attribute optional, by restriction?

Hello Rainer,

> When deriving a type by restriction, I do not think that it is a
> valid restriction for an attribute to an allow an use="optional", if
> the same attribute is required in the base type.

You're absolutely right, it isn't allowed. Whatever processor allowed
it has a bug.

> I must admit that it is very hard for me to read the Structures. It
> makes it even harder, because I´m not a native speaker. But enough
> of that. I thought that the following exerpt
>
> Schema Component Constraint: Derivation Valid (Restriction, Complex) 
> 2.1 If there is an attribute use in the {attribute uses} 
>     of the {base type definition} (call this B) whose 
>     {attribute declaration} has the same {name} and 
>     {target namespace}, then all of the following must be true:
> 2.1.1 one of the following must be true:
> 2.1.1.1 B's {required} is false. 
> 2.1.1.2 R's {required} is true. 
>
> would be an affirmation of my problem, I mentioned in the first
> question. But regarding the facts I´m facing, this can´t be true.
>
> My second question is:
> What is this exerpt talking about, what am I expected to learn from
> it? Because the heading says, "Schema Component Constraint", can
> this exerpt be theoretical in some way?
 
When a validator reads in an XML document that is a schema, it
translates the XML elements and attributes into "schema components".
"Schema Component Constraints" are constraints on the components that
make up this abstract internal representation of the schema, rather
than "XML Representation Constraints", which are constraints on the
XML document that is a schema.

The reason that there's a distinction is that it would be perfectly
possible for someone to create a purely virtual form of a schema that
never had an XML representation -- that was never serialized as an XML
document or represented as a DOM. The "Schema Component Constraints"
would apply to this purely abstract schema, even though the "XML
Representation Constraints" would never be relevant.

The excerpt you specify is talking about the constraints that apply
when you derive one complex type from another. It's saying that if you
specify the same attribute in the derived type as you already have in
the base type, then either the attribute in the base type must be
optional or the attribute in the required type must be required. You
could draw a little table:

                               Base type
                      required          optional

           required     OK                OK
 Derived
 type
           optional     BAD               OK

(It might have been clearer, I guess, if it had said "if the base
type's attribute is required then the derived type's attribute must
also be required".)
           
Cheers,

Jeni

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

Received on Thursday, 18 July 2002 07:26:43 UTC