RE: [xml-dev] Schema composition questions

["Shlomo Yona" <S.Yona@F5.com>]

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.  
> 
> This is exactly my question. I'm asking this from an
> XML processor implementation point of view and not
> from a schema author "best practice" point of view.
> I want to implement the "right thing" and the
> correct behavior. My problem is that I do not
> understand from the recommendation what is exactly
> the correct behavior.
> 
> [This is related to my 4th question]
> >>Paul: There is not a problem with circular
> includes per se.
> >>Namespaces aside, the spec says that duplicative
> includes/imports
> >>should be ignored.
> >>So just being circular is not an error.
> >>Now with namespaces, you are better off avoiding
> this kind of 
> >> behaviour because tools may interpret it
> differently.
> 
> Again, I want to implement the correct behavior into
> my XML processor. I'm not asking this as a schema
> author. Can you point out the proper way to handle
> such cases? Where in the recommendation is this
> issue being discussed and how is it suggested to
> process a set of XML schema documents that have
> circular dependencies in the general case?
> 
> [This is related to my 5th question]
> >>Paul: not sure I understand here.
> >>If it is about coercion of the namespace of the
> any, then I refer
> >>to earlier comments.
> >>If it is about what other options are available
> for namespace 
> >>declaration of any, then there are options such as
> "##other" 
> >>for specifying a different namespace, "##any" for
> any namespace,
> >>and there are some others too.  The spec lists
> them.
> 
> I was probably not clear. Let me try with an
> example:
> 
> A (tns "A") includes B (no tns) which includes C (no
> tns) which imports A.
> C contains: <xsd:any namespace="A"/>.
> To which top level names does this wildcard refer
> to?
> Only those listed in the A schema document?
> Perhaps those listed in B too?
> Perhaps those in A, B and C?
> 
> I can give other examples where this is complicated
> for me to understand, for example:
> 
> A (tns "A") includes AA (tns "A") and also includes
> B (no tns) which includes C (no tns).
> C contains: <xsd:any namespace="A"/>.
> But to which top level names does this wildcard
> refer to?
> What if AA contains <xsd:any namespace="A"/>?
> To which top level names does this wildcard refer
> to?
> 
> Of course, there are plenty more other examples to
> cook up which are, at least for me, similarly
> unclear.
> 
> 
> 
> I hope that you and the other experts here can help
> me out.
> 
> Thanks.
> 
> Shlomo.
> 
> 
> 
> 
> 
> 
> 



      ___________________________________ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: http://it.docs.yahoo.com/nowyoucan.html