[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Schema composition questions

  • From: Michele Vivoda <idmichele@y...>
  • To: Shlomo Yona <S.Yona@F...>, xml-dev@l...
  • Date: Sun, 15 Jul 2007 17:03:44 +0200 (CEST)

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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.