• To: xml-dev@l...
• Subject: Re: If XML is too hard for a programmer, perhaps he'd be better off as a crossing guard
• From: Sean McGrath <sean.mcgrath@p...>
• Date: Fri, 28 Mar 2003 20:38:58 +0000

 >>Dare Obasanjo wrote:
 >>The "Desperate Perl Hacker" argument  was a bogus claim for XML 1.0 
because of the existence of
 >>entities and CDATA sections but is quite farcical now with the existence 
of the Namespaces in XML
 >>recommendation (and it's bastard spawn "QNames in content").

[Tim Bray]
 >Empirically false, at two levels.  First, lots of people process XML with 
perl (or equivalent) all the time.
 >Second, the real requirement was to make it tractable to take a large 
body of document data and make
 >quick programmatic changes on it.  Which, obviously, XML makes way easier.

Ah, but what if the programs are *wrong* because of the failure to take 
account of all the lexical complexities
required to make such programs *correct*. Just because lots of people do 
it, don't make it right.

Right?

Lets focus on a simple, straight question.

Lets imagine we are developing a mission critical application - a life 
support machine.

We need to detect the pulse of a patient in the data stream. There is a 
<pulse> tag that contains
the data we want. What is the shortest *correct* program to extract out the 
pulse figures using regexp?

I would argue it is a complete XML 1.0 WF parse! If it ain't, I'm not 
buying that life support machine. If I'm charged
with developing the application, I'm firing any programmer that uses regexp 
to implement!

Sean


http://seanmcgrath.blogspot.com

• Prev by Date: Re: XML into SQL and out again
• Next by Date: Re: Re: If XML is too hard for a programmer, perhaps he'd be better off as a crossing guard
• Previous by thread: RE: If XML is too hard for a programmer, perhaps he'd be better off as a crossing guard
• Next by thread: RE: GXA specifications process
• Index(es):
  • Date
  • Thread