Making Progress

January 12, 2000

Edd Dumbill

Holiday festivities behind us, it's back to work, and good progress is being made in the XML community. Work on the SAX2 specification is gathering momentum, and the breakaway SML-DEV list is becoming a very colorful and active place.

The last week has seen much activity surrounding SAX2, the second version of the Simple API for XML. SAX is a standard for XML parser APIs that is being developed collaboratively on the XML-DEV mailing list under the coordination of David Megginson.

As further parts of XML have become standardized (e.g. Namespaces), support for them in APIs is becoming increasingly important. This support allows for practical use of the new standards by users.

Licensing

One of the topics under discussion this past week was licensing. David Megginson posted a question to XML-DEV asking under which license SAX2 should be released.

As we move to SAX2, I was wondering what licensing we should use? Is public domain still OK? It is very important to me, at least, that SAX's license be as friendly as possible to commercial software developers...

Some people replied with licensing suggestions, but a convincing argument from Paul Prescod suggested that, since an API specification is not itself software, it can't be licensed with a software license. To illustrate his point, Prescod took on two fictitious roles: "Let me pretend to be a lawyer, then a consultant."

Pretend Lawyer:

...I observe that it is the implicit consensus in the computer community that APIs, protocols, and so forth are either not protectable or that the case is so likely to go against you that it isn't worth trying.

Pretend Consultant:

... If you want to allow anyone to use SAX anywhere in any way for any project, then what's wrong with putting it in public domain? Other licenses exist to stop some particular action (e.g., commercial use). What are you trying to prevent?

I use implementations of SAX (parser, app and infrastructure library) that do not in any way use code from your site. I don't see how your license can affect that use at all.

Unfortunately, there still remains a problem to solve. How will the originators of SAX protect use of the org.sax.* package namespace in Java if there is no licensing? Tim Bray highlighted this issue and asked if there was anything that could be done in licensing, trademark, or copyright law to help.

The final push

David Megginson reiterated his desire to get SAX2 released. He presented a nine-point plan for SAX2 and asked for comments. It is of note that a good proportion of the ensuing debate covered the handling of XML Namespaces, a specification that has been causing trouble elsewhere in the last week. Little wonder that Megginson is keen to release SAX2 and solve some of these problems for users:

[Leigh Dodds]
> In this instance, though, your level of surprise is going to relate
> to how familiar you are with the Namespaces spec.

Expect close to zero, here—judging by the e-mail I receive, most people who use SAX haven't even read the XML 1.0 REC much less the Namespaces REC, and I wouldn't expect them to have done so. After all, they're programmers who have to deal with XML as one (often small) part of their work, not XML specialists.

Questions about XML Namespaces continue to crop up on XML-DEV. This week's debate centered around the namespaces of attributes. Given:

 <d xmnls:p="http://xml.com/someURI"> <p:foo bar="baz"/> </d>

...which namespace is the bar attribute in? Is it in the same one as the element foo? This was essentially the question asked by David Hunter in connection with XSLT processing.

David Megginson re-framed the question, asking whether the attribute names in the following two examples are identical:

 <html:a href="foo"> <html:a html:href="foo">

Tim Bray presented an explanation in response to Bob Kline's understandable complaint of "getting lost in the medieval subtleties":

The namespace spec could have said one of three things:
1. These must always be treated as identical.
2. These must always be treated as different.
3. Applications can make up their minds.

The then-Working Group eventually went for #3.

So, the answer appears to be "it depends on the application." Read on for some interesting comments on "junk" in standards.

Marching to the beat of a somewhat simpler drummer is the crowd on the SML-DEV list. Since its formation several weeks ago (see XML.com articles by Robert La Quey and Rick Jelliffe), the list has been very active. Don Park posted a status report of SML to the XML-DEV mailing list, reporting on the group's progress and on some of the more interesting concepts being addressed.

Based on discussions posted thus far, Don Park presented the mailing list's current consensus on what SML does and (more controversially) does not contain. Notably, the group has decided that SML will be a strict subset of XML. Of the group's main goal of the moment, Park had this to say:

We are currently trying to formulate an information model for SML before moving forward to tackle tougher issues such as attribute, mixed content, and namespace support. I think SML represents a unique opportunity to do things right in the right order. In contrast, an XML information model is still being worked on, two years after XML syntax.

One of the more innovative notions to arise from the SML-DEV group is the assertion that SML is a black-and-white language (the two colors being "name" and "value"), as opposed to the more colorful XML. A visual illustration showing the SML interpretation of an XHTML document is available online.

Park concludes his message reflecting, somewhat portentously, on the SML-DEV list members' interest in e-commerce:

Just as the design of XML was influenced by the primary interests of its inventors, publishing documents on the web, SML's design will likely be heavily influenced by our interests in e-commerce and data exchange. After all, SML will be our child.

A community-spirited Roger Costello has released a free XML Schema Tutorial. XML-Deviant reported last week on various clarifications of the XML Schema specification in XML-DEV, Costello being among the protagonists. His tutorial, available from http://www.xfront.com/xml-schema.html, draws in part on those discussions from the XML-DEV list.

Also helping us to understand the important XML Schema specification is Curt Arnold. He announced to XML-DEV the release of an HTMLHelp file for the December XML Schema Working Draft:

This help file is being provided to assist the XML community in understanding and refining XML Schema as it approaches recommendation status. The help file is extensively cross-linked and indexed, supports full text search, has content model diagrams for all elements, and has links to pertinent public comments and XML-DEV threads.

The file can be obtain from the AEA Technology - Engineering Software web site.

In continuation of a thread from last week concerning Peter-Murray Rust's wish for an open source XML editor API, Lauren Wood, chair of the W3C DOM Working Group, invited submission of requirements for any DOM Level 3 functionality. (Concerns had been raised regarding the sufficiency of the DOM for providing an editing API.)

So if there are things you really need, please send a list of them to www-dom@w3.org. Especially if they're already in some existing DOM implementation. It's too late for Level 2, but we're busy writing a requirements document for Level 3, so now is the right time to get them listed. If you can include a use case, that makes life much easier for everyone, of course.