xml-dev - Re: XML Middleware

[Dave Winer <dave@userland.com>]

Oooops, I clicked the Send button before editing.

There has to be XML in there somewhere for it to be XML middleware.

It could be in the interface to the database (send XML queries to the
database, receive XML back) or it could be in the interface to the Web
browser (send XML and have it rendered through XSL.)

Still diggin.

Dave


----- Original Message -----
From: "Dave Winer" <dave@userland.com>
To: "J.G.A. Mallaparaju" <raj@pacific.net.in>; <xml-dev@lists.xml.org>
Sent: Tuesday, August 22, 2000 9:37 AM
Subject: Re: XML Middleware


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