xml-dev - XML in the real world... Was "Re: Another look at namespaces"

[Tyler Baker <tyler@infinet.com>]

Ann Navarro wrote:

> At 11:43 AM 9/16/99 -0400, Hunter, David wrote:
> >(If I develop an Intranet application, I want to be able to
> >use XHTML without clients having to run out to the W3C site regularly.
> >Ditto for any other XML vocabularies which are defined going forward, from
> >the W3C or anyone else.)
>
> It also should be noted that there's nothing precluding a cache'd copy of
> that "thing" for that Intranet application.

True, but I think all of this misses the point here. Since November 1997 when I started
working with XML, I have never once found any need for a DTD or some other Schema language for
the applications I have written which use XML. For databases, schema's I feel are very
necessary, but I just have not found any real-world use for DTD's or schemas to date other
than as a technical document a programmer can refer to.

Add in what namespaces do to DTD's and Schemas in general and you effectively have no real
reason to produce documents that would be processed by a validating XML Parser.

The one exception I can think of is an abstract element tree like the DOM where you want to
make sure you have a valid document since the DOM itself has no way of enforcing a document
type during the tree building process.

In the case of most applications, they build there own data structures directly from an
event-based XML parser or else from some sort of object-oriented framework which delegates the
events to some sort of abstract element API. If you get an unknown form of element content,
the application can choose how to handle it as it wishes. Whether this element content is
supposed to be there is defined by programmer documentation which may include a DTD as a
reference (such as in the XSLT spec). If expected element content does not occur within the
scope of the containing element being processed, then the application can fill in the default
values as it sees fit.

In the case of internal general entities (if you choose to use them), you can handle all of
that business at the application level as well, therefore eliminating the need for DTD's or
schemas.

In the case of XHTML and this whole debate about 3 namespaces vs. one namespace, in theory the
3 namespaces proposal makes much more sense than having just one namespace. In reality, for
not just software, but average web netizens as well who believe it or not still sometimes like
to code HTML by hand or at least post-edit the content generated from their very poor and
universally incompatible HTML editing tools, having three namespaces just exponentiates the
confusion.

So the fact this list is arguing about document science concepts for a markup language whose
intended audience is virtually anyone on the internet who wants to build a web page, totally
misses the point. We need to ask the question "how does this impact the users of this
wonderful new markup language we are proposing".

To date, I have only seen a handful of comments on this issue and since I write software for
users for financial gain, and not for personal adulation, I ask myself these questions all the
time when I write a new software module that has some end-user interaction associated with it.

Hopefully the W3C is more concerned with creating an XHTML spec of practical use rather than
some piece of art that CS 101 students will reflect on 100 years later as something beautiful
but "never caught on with the masses". What seems like the best solution sometimes is not
always the most satisficing to your real goals.

Tyler Baker


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)