xml-dev - Re: XML Middleware

[Dave Winer <dave@userland.com>]

There's a narrow and a broad definition. The narrow one, which is more
common is software that accesses relational databases and interfaces to
users through the Web and HTML.

The broader definition allows any kind of back-end and any kind of
front-end.

Usual disclaimers, ymmv, imho, afaik etc.

Dave


----- Original Message -----
From: "J.G.A. Mallaparaju" <raj@pacific.net.in>
To: <xml-dev@lists.xml.org>
Sent: Tuesday, August 22, 2000 8:36 AM
Subject: XML Middleware


> 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
> >
>