[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Schema composition questions
Hi, > So, regarding 5, I understand that wildcards > represent names that "exist" (defined/declared) in > the same schema document or in schema documents that > are imported or included into it. Right? Perhaps is better to forget documents.. Wildcards 'validate xml attribute and elements based on their name and namespace'. [[A wildcard provides for ·validation· of attribute and element information items dependent on their namespace names and optionally on their local names.]] In practice wildcards are made of a pattern that accepts or rejects some namespaces (and some local-Names from 1.1.). Where is defined the component, in which document, is not relevant (and not known) after that you resolve the include/import chain and you got all the names and TNS resolved. The wildcard pattern depends on the @namespace attribute, but this is not enough to determine the actual pattern. A wildcard-component contains a possibly empty set of namespaces: when a wildcard use in its *definition* (@namespace attr) one keyword (like ##local) that, with no include, ''would generate'' a {namespace-set} containing the 'absent-namespace', if the document *has no TNS* and is included in an other document with not absent TNS (cfr 4.2.1 - Clause 2.3, 3.2) then the {absent-namespace} in the {namespsace- set} must be replaced with the TNS of the including document (Clause 3.2.2). For example when including into a doc with TNS {A} a doc with absent-ns and a wildcard with namespace='##local': 1) some(*) elements/attrs of the included doc take namespace {A} 2) the wildcard (as effect of the replacement of the TNS) will validate names of namespace {A}. (*) global elements/attrs and local with @form='qualified' If someone thinks this is wrong, please let me know. >This means > that wildcards do not reference names that are > declared/defined in including/importing schema > documents. Is this what you mean? no, documents do not matter anymore after that you resolve the names, only name+ns matter. In the previous example the wildcard will validate also names of the including schema. Michele Vivoda --- Shlomo Yona <S.Yona@F...> ha scritto: > Hello, > > The link is indeed interesting. Thanks. > So, regarding 5, I understand that wildcards > represent names that "exist" (defined/declared) in > the same schema document or in schema documents that > are imported or included into it. Right? This means > that wildcards do not reference names that are > declared/defined in including/importing schema > documents. Is this what you mean? > > > > > Shlomo. > > -----Original Message----- > From: Michele Vivoda [mailto:idmichele@y...] > Sent: å 13 éåìé 2007 17:27 > To: Shlomo Yona; xml-dev@l... > Subject: Re: Schema composition questions > > Hi, > > when I have doubts about include/composition > I often look to this illuminating post: > > http://xsd.stylusstudio.com/2004Oct/post01000.htm# > > For question 5, I was looking at it yesterday > and from what I read in (4.2.1), > wildcards in included > documents that have in the {namespace constraint} > [this property is now {namespaces} in Schema 1.1] > the {absent-namespace} should be changed > substituting > the {absent-namespace} with the <inlcud>ing > namespace, > > I believe. > > I think that wildcards are much better treated in > schema 1.1 (and they should be also compatible with > 1.0). > > > An other question could be what happens if I > really mean to skip all no-ns attributes > > <xs:anyAttribute namespace='##local' > processContents='skip'/> > > and then I include... > > Perhaps an answer is in Schema1.1 - 4.2.1, > where there is this note: > > Note: If a schema document is to be included in a > way > as described in clause 2.3, then it should avoid > using either ##other or ##local in a wildcard, > because the result of the inclusion will not be the > same as if the schema document being included had a > targetNamespace [attribute] that is the same as > that > of the including schema document. > > Regards, > Michele Vivoda > > > > --- Shlomo Yona <S.Yona@F...> ha scritto: > > > Hello, > > > > I hope that it is appropriate to post a link to a > > thread in xmlschema-dev, where I could not get a > > response (other than that of Paul Kiel, who tried > > kind to answer from a schema author's point of > > view). > > > > I have some questions which are related to schema > > composition. I read the XML Schema recommendation > > and was not able to understand the desired correct > > behavior in some cases. > > > > I hope that some of the experts here can help me > by > > shedding some light on this. I need the > perspective > > from an implementation of an XML processor rather > > than the one of a schema author (although that > > perspective can surely give some insights as > well): > > I'm trying to understand how it is expected to > work, > > not design patterns that work around > incompatibility > > issues. > > > > The original questions were asked here: > > > http://lists.w3.org/Archives/Public/xmlschema-dev/2007Jul/0001.html > > > > Some more examples for "what I mean" are listed in > > my response to Paul Kiel below. > > > > Thanks for your help > > > > Shlomo. > > > > -----Original Message----- > > From: xmlschema-dev-request@w... on behalf of > > Shlomo Yona > > Sent: Sun 7/8/2007 10:41 AM > > To: Paul Kiel; xmlschema-dev@w... > > Subject: RE: schema composition questions > > > > > > > > Hello, > > > > > > [This is related to my 1st question] > > >>Paul: this is certainly legal and useful. It is > > called "namespace > > >>coercion" because you are coercing the schema B > > into the namespace A. But > > >>if the nesting gets more complicated it > sometimes > > is not exactly > > >>interoperable across implementations. We ran > into > > trouble using this some > > >>time ago. > > > > I think that I understand what happens in a > trivial > > case such as this: > > A (tns "A") includes B (no tns) > > > > All the top level names in B are now in the > > namespace that A declares as its target namespace > > (tns "A"). > > > > What I don't understand is the case where > > A (tns "A") includes B (no tns) which imports C > (tns > > "C"). > > Is this a legal situation? > > What is the fully qualified name of top level > names > > from C in the composed schema document? > > I would argue that the following possibilities > > should be considered (I am not sure that I listed > > all possibilities and am not sure at all which is > > the correct or desired behavior): > > * This is illegal and the whole schema processing > > fails > > * A include B import C fails (not all top level > > names in the composed B and C can be coerced into > > the target namespace of A) and the result is only > A > > include B (ignoring the import of C into B) > > * The composed schema is only A itself due to > > failure of coercing all the names in the composed > B > > and C schema documents > > * The composed schema document includes top level > > names in A under the target namespace "A" + top > > level names in B under the target namespace "A" + > > top level names in C under the target namespace > "C". > > > > So... what is the correct or desired behavior? > > > > > > > > [this is related to my 2nd question] > > >>Paul: The ordering is not significant here. > > > > Is it always the case that the order of processing > > xsd:import and xsd:include in a schema document is > > insignificant? Or are there examples where order > > matters? > > > > > > [This is related to my 3rd question] > > >>Paul: This is where interoperability can be a > > problem. > > >>I would suggest that you keep it to one no-ns > > schema being > > >>included into one ns schema. > > >>If you have multiple levels of includes and > > multiple levels > > >>of "coercion" then tools can interpret that > > differently. > > >>To be frank, we ran into problems with namespace > > coercion > > >> and decided to abandon it altogether. > === message truncated === ___________________________________ L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|