xml-dev - XML Middleware

[raj@pacific.net.in (J.G.A. Mallaparaju)]

dear all:
I need a clarification.
I've come across (While reading a document on WAP), a term- "XML
Middleware". What does it mean?
Thanks in advance.
Raj
----- Original Message -----
From: james anderson <james.anderson@mecomnet.de>
To: <xml-dev@lists.xml.org>
Sent: Tuesday, August 22, 2000 3:49 PM
Subject: Re: Requirements for making DTD validation work with namespaces


>
> Perhaps "contradicts" is not adequate. Perhaps "supersedes" is better.
> While a processor which tracks both cat-1/2 validity and cat-5 validity
> is conceivable, I'd be surprised if it were worth the effort. My sense
> of the data model which would be effective to support those respective
> validity criteria which concern symbol identity is that it would be
> "difficult" to manage an efficient representation which supported
> cat-1/2 and cat-5 categorizations simultaneously, and thus it would be
> necessary to maintain distinct, duplicate models. In the sense that the
> duplication entails time and space demands to which one would not likely
> wish to accede, the categories "contradict" each other. Where I follow
> my prejudices, the "cat-5 adequate" model is better for the cases which
> I find useful, so I don't bother with the "cat-1/2 adequate" model. In
> that sense cat-5 "supersedes".
>
> Case in point: "naive DTD integration". Where two document types have
> been designed without regard for namespaces, the respective DTDs may
> well each contain declarations for elements with the same unprefixed
> QName, for example
>   <!ELEMENT element ... >
> This would violate the "unique element type declaration" constraint and
> imply a cat-2 status. Should the processor be cat-5, then the presence
> of the following in the internal subset
>   <!ATTLIST element xmlns CDATA #FIXED "namespace1">
>   <!-- read first dtd -->
>   <!ATTLIST element xmlns CDATA #FIXED "namespace2">
>   <!-- read second DTD -->
> should well entail the two distinct universal names {namespace1}element
> and {namespace2}element. [Scoping rules, such as those required for such
> a mechanism, are implied by the passage which describes the "prefix
> declared" namespace constraint. The spec, unfortunately, never says what
> they are.] Should a processor wish to model names such that it is
> capable of this form of distinction between universal names - a form
> which is necessary for useful cat-5 judgments, and, "at the same time"
> also make cat-1/2 judgments, then, I suggest, it will need to duplicate
> many aspects of its document model.
>
>
> "Winchel 'Todd' Vincent, III" wrote:
> >
> > >
> > > >The mechanism to which I alluded below neither ignores the problem
nor
> > > >does it entail parameter entities, and it conforms to three of the
five
> > > >constraints. Item 5 contradicts 1 and 2 and it doesn't make sense to
> > > >implement both.
> > >
> > > I don't see how item 5 contradicts 1 or 2.
> > >
> > > It creates a new category of documents, distinct from "valid" and
> > "invalid",
> > > as defined in XML 1.0.
> >
> > I don't see how item 5 contradicts 1 or 2 either.  The use of the word
> > "SOME" might be changed.  So, for instance, this might be better:
> >
> > >    5. SOME XML 1.0 documents that are Well-Formed, Invalid, and
conform to
> > > >the XML Namespaces REC, are considered to be "Namespace-Valid".
> >
> > 5. Namespace-Valid documents are well-formed, conform to the XML
Namespace
> > REC, but would be invalid but for Namespace-validation.
> >
> > That is a bit awkward too, but it is more precise than "some".
> >
> > Otherwise,  these requirements are excellent.
> >
> > >
> > > How you define this category is the whole point - everyone seems to
have
> > > ideas about this.
> > >
> > > I will not budge from requirements 1 - 3.
> > > 3 is where a lot of proposals fall down.
>
> As I suggest as well.
>
> >
> > When you say, "All namespace declarations work just as in XML Namespaces
> > REC," does this mean, they all work as they would in non-validating and
> > validating parsers, but they work differently in a Namespace-validating
> > parser, because the behavior of such a parser must be different to
validate
> > a well-formed document against two or more DTDs?
> >
> > I don't see how this will work (without changing XML 1.0 or Namespaces)
> > without creating a new class of parser.  Of course, this changes parser
> > behavior described in the specs, but it does not change the syntax
mandated
> > by the specs. [...]
>
> It's not a new moninal class. It has been entailed in the specs all
> along. Its implementation may have been rare, but that's another issue.
>
> >
> > Todd
>