RE: [xml-dev] Schema composition questions

[Michele Vivoda <idmichele@yahoo.it>]

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@F5.com> 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@yahoo.it] 
> Sent: å 13 éåìé 2007 17:27
> To: Shlomo Yona; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] 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@F5.com> 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@w3.org on behalf of
> > Shlomo Yona
> > Sent: Sun 7/8/2007 10:41 AM
> > To: Paul Kiel; xmlschema-dev@w3.org
> > 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