[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: If XML is too hard for a programmer, perhaps he'd be bett

• To: "Sean McGrath" <sean.mcgrath@p...>,<xml-dev@l...>
• Subject: RE: If XML is too hard for a programmer, perhaps he'd be better off as a crossing guard
• From: "Dare Obasanjo" <dareo@m...>
• Date: Fri, 28 Mar 2003 13:05:00 -0800
• Thread-index: AcL1attzMtgdaPVgSWi8ihyzD5VfFQAAPJdw
• Thread-topic: If XML is too hard for a programmer, perhaps he'd be better off as a crossing guard

Thanks Sean, 
  This is exactly what I was thinking when Tim responded. Using regexes
to process XML may work in cases where you have complete control over
the input XML but is folly when one extends it to situations where does
not have full control of the XML input such as the WWW. I'd suggest Tim
reread Joe Gregorio's articles on regex-able XML and take a good look at
the problems he's had processing arbitrary RSS feeds. 

Also as you suggest, in mission critical systems relying on regexen is
extremely unwise. 

-- 
PITHY WORDS OF WISDOM 
You can never tell which way the train went by looking at the track.


This posting is provided "AS IS" with no warranties, and confers no
rights. 

>  
>  
> -----Original Message-----
> From: Sean McGrath [mailto:sean.mcgrath@p...] 
> Sent: Friday, March 28, 2003 12:39 PM
> To: xml-dev@l...
> 
>  >>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
> 
> 
> 
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org 
> <http://www.xml.org>, an initiative of OASIS 
> <http://www.oasis-open.org>
> 
> The list archives are at http://lists.xml.org/archives/xml-dev/
> 
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
> 
> 

• Follow-Ups:
  • Re: If XML is too hard for a programmer, perhaps he'dbe better off as a crossing guard
    • From: Paul Prescod <paul@p...>

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