OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters for NamespaceProcessing)



Kohsuke,

Having read your xml.com article, I understand that you are against
locally-scoped elements - as well as anything else that doesn't make XSDL a
dumber version of RELAX, as you blithely recommend.  Please understand that
this entire discussion is _only_ about locally scoped elements and has no
relevance to anyone not using them.  Please also note that locally scoped
elements are _not_ just elements whose declarations occur in a funny
location in a schema. They actually _are_ a different beast from global
elements and _must_ be treated as such.  I don't think that the W3C Schema
WG ever really came to grip with this fact, given the inadequate support
provided for them by spec's component model.

As someone who was in the original W3C XML SIG when namespaces were first
discussed, I find your email rather humorous and I'd like to recast it
(slightly) to show why.  I wonder if local names engendered the same
antipathy in Algol60, or there abouts, when this "unimaginable...cool trick"
was introduced. Plus ca change...!

> -----Original Message-----
> From: Kohsuke KAWAGUCHI [mailto:kohsukekawaguchi@yahoo.com]
> Sent: Friday, August 17, 2001 5:00 PM
> To: Xml-Dev
> Subject: Re: Namespaces, W3C XML Schema (was Re: ANN: SAX Filters for
> Name spaceProcessing)
> 
> 
> 
> > be mixed.  Therefore the appropriate solution would be to get rid of
> > elementFormDefault and provide appropriate mechanisms in 
> the _instance_ to
> > specify how this should work for the particular instance under
> > consideration.
> 
> Wow, I can't believe what I see.
> 
> So you are saying that
> 
> <p:root xmlns:p="abc"
>         xsi:elementFormDefault="qualified">
>    <p:child/>
> </p:root>
> 

<p:root xmlns:p="abc">
  <p:child/>
</p:root>

> and 
> 
> <p:root xmlns:p="abc"
>         xsi:elementFormDefault="unqualified">
>    <child/>
> </p:root>
> 

<root xmlns="abc">
  <child/>
</root>

> are both valid, and an application is expected to behave in 
> the same way?
> 
> 
> I assume that you are not saying that this 
> xsi:elementFormDefault thing
>  does not change the way namespace URI is interpreted.
> 

I assume that your are not saying that this xmlns thing does not change the
way an element is interpreted.

> If so, your proposal means that an application must rely on PSVI of
> an element, rather than the namespace URI of that element, to decide
> what to do with that element because the namespace URI can be either
> "abc" or "".
> 

If so, your proposal means that an application must rely on processing of
namespace attributes, rather than just element names, to decide what to do
with that element because the element may have a namespace or not.

> 
> How can we expect that all applications recognizes
> the xsi:elementFormDefault attribute and behave correctly? No way.
> 

How can we expect that all applications recognizes (sic) the xmlns
attributes and behave correctly?  No way.

> This is nothing but a nightmare to me.
> 

As namespaces seemed to many when first introduced - including many of the
most brilliant people in the community.

> 
> regards,
> ----------------------
> K.Kawaguchi

Any of a huge number of old SGML/early XML users circa 12/97

> E-Mail: kohsukekawaguchi@yahoo.com
>

So, having lived through the introduction of namespaces, I don't see any
particular problem with local elements - we were using them in SOX before
they showed up in XSDL.  They actually fulfil a very similar use to
namespaces - distinguishing uses of the same local name, but note that the
current namespace mechanisms provided by XML Schema are inadequate for local
element support.  Part of the XML Schema Formal Description is attempting to
deal with that, especially with the introduction of normalized names for all
schema components.

Matthew