Home. 
.

transparent

transparent

transparent

Altova Mailing List Archives


Re: comments and PIs in XML Schema

From: "C. M. Sperberg-McQueen" <cmsmcq@-------------.--->
To: Michael Kay <mike@--------.--->
Date: 4/25/2009 4:00:00 AM
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
****************************************************************





From mrglavas@c... Sat Apr 25 17:34:47 2009
Received: from maggie.w3.org ([193.51.208.68])
	by frink.w3


transparent
Print
Mail
Like It
Disclaimer
.

These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on www.altova.com/list/index.html. Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.

.
.

transparent

transparent