[Prev][Next][Index][Thread]

Re: XML Conformance Levels [Was: ERB Decisions of March 26th]



Jon Bosak wrote:

> One of the most basic design principles for this whole effort has
> been: Thou Shalt Have No Optional Features.  We're implicitly allowing
> for very large-scale optionality by dividing the spec into three parts
> (xml-lang, xml-link, and xml-style), because it's obvious that there
> will be database exchange applications that only need xml-lang, for
> example, and Java-based approaches like CML that will use xml-lang and
> xml-link but not xml-style.  I would powerfully resist any effort to
> get more granular than that.  The lack of options in XML is one of the
> very best things about it.

I'm not into optional features either but I am becoming ever more alarmed by
the possibility of "feature creep". As we get closer to a concrete, No 
Optional Features XML, I'm perceive that we are adding features because
we "need" the functionality. 

This is a fairly well-known phenomenon in product development - features get
added at the end of a development cycle because cycle times are too 
great and the perception is that people can't wait for the next release. 
Please, let's avoid this trap. Fortunately, we don't have to get
it *completely* right the first time. This is the Web. Things are expected
to change. XML can (must) evolve over time, and there is no requirement
that evolution occur at 10-year intervals. 

We have an opportunity to change the Web and we're on our way. We need more
proposals like those from Microsoft that clearly demonstrate the utility
and benefit of structure and semantic markup. We don't need more features.
We need a simple, easy-to-implement, easy-to-understand specification that
has broad applicability.

If conformance levels can enhance understanding, implementation, and 
acceptance then I'm for them. If we decide (as we have in the past) that
conformance levels do the opposite, than they should not be considered. An
option to conformance levels is to agree that XML will be revised (fairly)
frequently. By doing so, we could get out the simplest possible XML
immediately so as to encourage experimentation and development.