OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ubl-ndrsc] Rule: 91

On Fri, 18 Jul 2003, Eve L. Maler wrote:

>>Chin Chee-Kai wrote:
>>> If your "top-level" means "immediate child of <xsd:schema>",
>>> then "top level" is "global".   But what I'm saying is
>>> "naming" != "global".
>>I checked the XSD spec part 1 (http://www.w3.org/TR/xmlschema-1/), and
>>"global" is a concept that seems to be associated only with element and
>>attribute declarations, and only in the sense that their namespace scope
>>is global.  It doesn't refer to the positioning of a declaration or
>>definition within the <xsd:schema> element.  So maybe it's best avoided
>>here, since it's not very precise.

It's funny how when I flipped through the pages of XML Schema 
Part I, I got reminded of lawyers ploughing through the legal

Anyway, thanks for englightening more aspects of XML Schema.
I tend to agree with you that XML Schema Part I talks
about "global" almost consistently with use of "elements" only.
It is remarkably silent about talking about the concept of 
"global" with types.  

But I see a point with [R 91] to talk about a type being global
because such concept is not only applicable to programming 
languages, it also makes it easier to talk about types (whether 
named or unnamed) that are allocated at the "top-level" (immediate
children of <xsd:schema>) of a schema.

I believe I'm not alone in talking about "global" in the sense of
being an immediate child of <xsd:schema>.  For elements that you
mentioned, XML Schema Part I does have a paragraph saying (somewhere
in the midst of Section 3.3.2):

  "<element>s within <schema> produce global element declarations;
  <element>s within <group> or <complexType> produce either particles
  which contain global element declarations (if there's a ref attribute)
  or local declarations (otherwise)."

I concede that the notion of "global" being an immediate child
of <xsd:schema> is an indirect conclusion.  The sentence uses the 
notion of "depth" (within <schema>, or within <group> or
<complexType> which in turn must be within <schema>) to define
"global"ness.  As a given <element> must be in one or the other
depth location, the conclusion would be that if a given <element>
has depth 1, it is global;  else if it occurs within <group>
or <complexType>, it must have depth > 1 and so isn't global
(and not necessarily immediately concluded as being local).

Either way, perhaps we need to agree on what "global" means in
the context of [R 91], if there could be a chance of having
"global" being interpreted as any concept, such as "naming" 
or "being defined" (which to me, again, are very different 
concepts not to be interchanged easily without knowing the 

Best Regards,
Chin Chee-Kai
Tel: +65-6820-2979
Fax: +65-6743-7875
Email: cheekai@SoftML.Net

>>On the other hand, the XSD schema itself
>>(http://www.w3.org/2001/XMLSchema.xsd) does have a notion of
>>topLevelComplexType versus localComplexType; these are restrictions of
>>the complexType type and govern the definition of named vs.
>>anonymous/locally scoped complex types.  There are also
>>topLevelSimpleType and localSimpleType.  It looks as though the
>><redefine> element can contain the version of <complexType> that is
>>bound to topLevelComplexType.
>>So at the very least, maybe we should substitute "top-level" for
>>"global" if we determine that this rule should have that additional bit
>>of explanation on the end.
>>> Wait, I'm not saying anything about using or prohibiting
>>> <xsd:redefinition>,  all I'm quoting is that a named  complexType
>>> can be a non-immediate child of <xsd:schema>, thus giving a
>>> counter-example to the assertion that "naming" == "global".
>>> The original rule wordings were:
>>> [R 91]   All type declarations MUST be global.
>>> which says what it wants to say already.
>>> A rule about redefinition, if there's an intention to do so,
>>> would rightly be in a separate rule as you suggested.
>>(I know that redefinition was discussed at one time, but don't recall
>>the conclusion.  We should make sure that any decision on them is recorded.)
>>	Eve
>>Eve Maler                                        +1 781 442 3190
>>Sun Microsystems                            cell +1 781 354 9441
>>Web Technologies and Standards               eve.maler @ sun.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]