- From: Stanley Guan <Stanley.Guan@oracle.com>
- Date: Thu, 25 Oct 2001 12:25:29 -0700
- CC: www-xml-schema-comments@w3.org, xmlschema-dev@w3.org
I think, to answer the following questions, we need to take good practice of doing modularization and composition of schemas into consideration. And, should be enfornced by the standard if possible! sandygao@ca.ibm.com wrote: > Hi Henry, > > Thanks for the reply. > > Further on this topic: > > 1. If schema document A includes B, and B includes C. Does A have access to > components in C? And does C have access to A? In this case, A depends on B and B depends on C. A good design will enforce that A can access declarations and definitions provided in B, not C. Schema C should be hidden from B's user. The alternative way of exposing C to A is by doing: A includes B and C. (in this case, B should not depends on C). For the question -- "Does C have access to A", I think, from design point of view, it's a bad practice (i.e., violating the purpose of modularization). This creates interdependecy between C and A. > > > I think the answer is yes, according to your explanation below. > > 2. If schema document A includes B, and B *imports* C. Does A have access > to components in C? > Same as above. A good practice will not allow A to access C directly (note that A can still access C indirectly via B). The alternative design will be: A includes B and imports C. But, this could be a bad design if B still depends on C for its definitions. If B still depends on C, the user of B must always import C which is a bad design. > > From the spec [1], it seems A can't access C. But I want to be sure about > it. And if the above (1) is true, I would think (2) is true too. > > [1] http://www.w3.org/TR/xmlschema-1/#src-resolve > > Schema Representation Constraint: QName resolution (Schema Document) > ... > 4 its ·namespace name· is either the target namespace of the schema > document containing the ·QName· or that schema document contains an > <import> element information item the ·actual value· of whose namespace > [attribute] is identical to that ·namespace name·. > > Thanks, > Sandy Gao > Software Developer, IBM Canada > (1-905) 413-3255 > sandygao@ca.ibm.com > > > ht@cogsci.ed.a > c.uk (Henry S. To: Sandy Gao/Toronto/IBM@IBMCA > Thompson) cc: xmlschema-dev@w3.org, www-xml-schema-comments@w3.org > Subject: Re: clarification/errata: circular attributeGroup, > 10/24/2001 ur-type & include > 06:41 AM > Please respond > to ht > > > > sandygao@ca.ibm.com writes: > > > [3] include > > > > Assume schema document A includes schema documents B and C, where B has > the > > same target namespace as A does, and C has no target namespace. Then from > > within a certain document, components from which document(s) can be > > referred to? That is, how to fill the following table? (R(A,B)=Y means > > components in A can refer to components in B.) > > R A B C > > A Y Y Y > > B ? Y ? > > C ? ? Y > > > > >From the spec, it seems that B can refer to A (bullet 4 of QName > resolution > > (Schema Document)). How about the other question marks? > > The WG discussed your questions, and requested me to answer this one. > > All three documents contribute components to and resolve their > references in the single target namespace, so all cells in the table > should be 'Y'. > > This results from lazy resolution of references and the impact of > so-called 'chameleon' include (A, with a target namespace, includes C, > which does not, with the consequence that C's components are defined > in A's target namespace, and C's unqualified references are redirected > to that namespace as well). > > If there are specific places in the text of the spec. which encourage > other conclusions, please let us know and we'll try to improve them. > > ht > -- > Henry S. Thompson, HCRC Language Technology Group, University of > Edinburgh > W3C Fellow 1999--2001, part-time member of W3C Team > 2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440 > Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk > URL: http://www.ltg.ed.ac.uk/~ht/
Received on Thursday, 25 October 2001 15:26:12 UTC