[Bug 11290] {context} of simple types

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11290

--- Comment #3 from Sandy Gao <sandygao@ca.ibm.com> 2011-03-02 18:01:59 UTC ---
In the context of "2. In 3.4.2.2, {content type}.{simple type definition}"

> It seems to me that ... the values of ... follow from the rules of the spec.
> In some cases, they seem to me to follow from the statement that the type
> being described is a restriction of the other simple type identified

I agree this is possible, but it may impose some interesting ordering. There
are situations where we follow 3.x.2 rules to construct "things" (not yet
components, as they could turn out to be bad), then we check 3.x.6 rules. What
you suggest above seems to require that if 3.x.2 is not explicit about a value
of a property, then we use "a/the" value that will pass tests in 3.x.6. I'm not
confident that this is an established practice, and whether it's easy to
understand/implement. What if there are more than 1 values that pass 3.x.6?

> in other cases (e.g. {name}) they follow from the rules about how simple
> type definitions get their names.

In this particular case, the simple type definition does *not* correspond to
any <xs:simpleType> element, so rules in 3.16.2 don't apply. This is similar to
other cases where we *synthesize* a component (i.e. with no corresponding
source in the schema document), e.g. for (mixed/extension) particles.

> I agree that the nearest enclosing complex type is the natural choice.

Agree that it should be the "nearest".

> is it worth adding type table to this list for this situation? 
> Would it not be better just to use the enclosing element declaration?

I thought I had a reason for favoring the Type Alternative over the element
decl, but I can't remember it now.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 2 March 2011 18:02:02 UTC