W3C home > Mailing lists > Public > xmlschema-dev@w3.org > April 2009

Re: comments and PIs in XML Schema

From: C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com>
Date: Sat, 25 Apr 2009 10:00:11 -0600
Cc: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>, "'Mukul Gandhi'" <gandhi.mukul@gmail.com>, <xmlschema-dev@w3.org>
Message-Id: <81D72A52-3E24-4AFE-8B3A-2CE3AD4D2830@blackmesatech.com>
To: Michael Kay <mike@saxonica.com>

On 25 Apr 2009, at 03:02 , Michael Kay wrote:

>
> I think one way of looking at this is that if you want formal  
> constraints on
> where comments and PIs appear, then you shouldn't be using comments  
> and PIs,
> you should be using elements.
>
> It's true, of course, that comments and PIs are open to abuse. I've  
> been
> known to put data in PIs because the schema wouldn't let me put it  
> anywhere
> else. But I think one of the reasons XML works well is that it  
> allows you to
> use dirty tricks when you're stuck - systems need to have a bit of
> flexibility built in.

+1

And ideally, when you have to use a dirty trick, you want to have
an easy way to find it later, label it, or distinguish it from the
non-dirty context, so that it can when appropriate be cleaned up.

As Nathaniel Borenstein put it in Programming as if People Mattered
(Princeton:  PUP, 1991), in the course of an argument that user- 
interface
code should generally be implemented first as quick and dirty
prototypes and then reimplemented more slowly and more cleanly
once the design stabilizes (pp. 118-119):

     In particular, it is important to remember, as you fearlessly
     cut corners, that if the final interface ends up looking
     anything like the current prototype, someone will probably
     have to come back and "uncut" all of these corners. ... This
     means that it is the professional responsibility of the
     prototype builder to *document* all the corners he cuts.
     ...
     For the programmer building a prototype user interface, ...
     it isn't shortcuts that are unprofessional, it is hiding
     them, or indeed failing to make them obvious.  A "good"
     prototype will be full of shortcuts, but each will be briefly
     documented on a list of things that need to be cleaned up,
     rewritten, or redesigned for the final version of the
     product.

I've always thought that the existence of processing instructions
in the design of SGML serves a sort of symbolic function (among
others):  PIs show us that descriptive markup was designed by
people who know and care about clean data and beautiful structure,
but who also know what it's like to have a 4 p.m. FedEx
deadline and to have to manually override some part of the
system which for currently obscure reasons is putting a
page break in the wrong place.  Getting real work done over the
long haul involves both the need to get it clean and keep it
clean, and the need to do something ugly if you don't know how
to do it beautifully -- and at the same time to mark what you
are doing as something different, which may need to be revisited
and cleaned up later.


-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************
Received on Saturday, 25 April 2009 16:01:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 January 2011 00:15:11 GMT