[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Enlightenment via avoiding the T-word
- From: "Fuchs, Matthew" <firstname.lastname@example.org>
- To: "'email@example.com'" <firstname.lastname@example.org>
- Date: Thu, 30 Aug 2001 12:08:38 -0700
There is "a reasonbly efficient and productive way of building the correct
match paths" which I described in my email: read the schema and use the
appropriate path to the local of choice. Yes, they may be nested
indefinitely deep, but for now, that's life. I stand by my claim that this
approach is robust in the face of local elements - and somewhat optimal, so
long as there is no other way to uniquely identify local names (which there
The indefinite nesting problem for local elements in Schema (as opposed to
the general "context specific semantics" problem, which applies to globals
as well [e.g., I treat the global "foo" if it's inside the global "baz"
inside the global "bar" differently than I do the global "foo" inside the
global "ding" inside the global "dong"]) is a side effect of the existence
of anonymous types - unnamed complexTypes that appear inside (local) element
declarations. It's this mutual recursion that's infinite. If we eliminated
anonymous complexTypes (which I'm not necessarily advocating), then this
would be a two level issue.
> -----Original Message-----
> From: Francis Norton [mailto:email@example.com]
> Sent: Thursday, August 30, 2001 11:51 AM
> To: Fuchs, Matthew
> Cc: 'Rick Jelliffe'; 'firstname.lastname@example.org'
> Subject: Re: Enlightenment via avoiding the T-word
> "Fuchs, Matthew" wrote:
> > As I explain above, a "push program" based on valid XSDL
> with local names is
> > not vulnerable if match statements to match global elements
> are qualified,
> > and match statements to match local names are not and
> include the parent in
> > the match path, is not fragile in the way you describe.
> This is only sweeping the dust under a different corner of the carpet
> unless one can prescribe a reasonably efficient and productive way of
> building the correct match paths to disambiguate unqualified local
> elements, which can after all be nested indefinitely deep.
> The Normalised Universal Names (NUNs) you describe in the XML Formal
> Description are probably the best model for this, but until there is a
> way of building this disambiguation support into applications using
> multi-Mb schemas, the problem is not in my view conclusively resolved.