Perl & XML

dooling writes: "Perl & XML is a well-written book that accomplishes what it sets out to do. It states in the preface that it is written for Perl programmers who want to learn about XML and what is available in Perl for XML processing. It achieves this goal, but little else. When you are done reading this book you will have been given an overview of Perl and XML, know where to begin to attack an XML document, and know where to look to find more information." For dooling's more complete review, read on below. Perl & XML author Erik T. Ray & Jason McIntosh pages 202 publisher O'Reilly and Associates rating 6 reviewer dooling ISBN 059600205X summary Good introduction to XML for Perl programmers.

The book starts out with a brief explanation of why XML and Perl are well-suited for each other. It then provides a teaser of things to come: an explanation of how to use the XML::Simple module. The first chapter concludes with some warnings and gotchas that seem a little premature since they have not really explained XML. Fortunately, most of these gotchas are covered in context later in the book.

The second chapter provides a whirlwind overview of XML -- covering its structure, DTDs, schemas, and XSLT (transformation). The discussion of XML in general, its history, and parts of an XML document are well done. They give someone who is familiar with static HTML the needed background to understand the structure of an XML document and the vocabulary used to describe it. Unfortunately, the discussion of where XML begins to distinguish itself from HTML, namely with DTDs, the new replacement for DTDs called schemas, and the transformation language XSLT, is too brief. They gloss over these topics with little explanation and few examples. That said, there are other books that do provide more in-depth coverage of XML (this book only promises an introduction).

The next five chapters cover Perl modules designed to process XML, starting with simple parsers and writers. Only methods and syntax relating to XML processing are explained. Therefore, if you are considering reading this book, you should be fairly comfortable with Perl and object-oriented (OO) interfaces to CPAN modules (nearly all the modules discussed provide OO APIs). Again, there are other books and perldoc documentation that cover Perl and it's OO features; so read them first if you are not familiar with OO Perl. If you are familiar with OO Perl, these chapters provide a good overview of the different ways XML can be processed (stream- and tree-based approaches), the advantages and disadvantages of each, and the Perl modules best suited for each approach. These chapters are the biggest strength of this book. The modules discussed in these chapters are by no means an exhaustive list of XML-related modules available from CPAN nor do the explanations of each module cover everything the module does. These chapters do, however, provide the reader with enough information that she can begin to process XML documents intelligently and know where to turn when she needs more information.

The next chapter, Chapter 8, covers XML tree iterators, XPath, XSLT, and XML::Twig. All of these topics are covered in a span of 16 pages (with only slightly over two pages dedicated to XSLT). Indeed, after reading the chapter, you may get the feeling that it was only included so the authors could cram more trite colloquialisms into the book. The short shrift given to these topics creates the impression, which is strengthened in the chapters that follow, that this book was rushed a bit to press.

Chapter 9 discusses applications of XML, including RSS and SOAP, and Chapter 10 is mostly example code. These chapters are intended to give you a feeling for what is possible without really giving you enough information to make it happen. The main problem with these chapters are the examples: the examples are long and the explanations are short. Thus, they are more useful as templates or a quick reference than for learning these topics in detail. Of course, the authors never promised you would be programming SOAP applications when you were done reading this book. And again, there are other books out there which discuss these topics in more detail. So the authors stay true to their promise throughout the book: they will introduce you to XML and tell you how to interact with XML using Perl, no more.

Personally, I found this book did, in general, give me enough information to get started using XML and pointed me where I needed to go to get more information. I am an experienced Perl programmer who is new to XML and comfortable with on-line documentation. This book seems to be written for people who fit this profile and who want to learn by doing (finding the answers to the "hard" questions as they arise). It does introduce a wide variety of XML-related topics and the Perl modules used to interact with them, which is what the authors promised to do in the preface. While it is by no means an authoritative text on Perl and XML, there is something to be said for keeping promises ...

Index As with most first-edition books, the index was adequate but not complete. For example, XML::Twig, which has an entire section covering it, does not appear in the index at all.

Contents
Preface

1. Perl and XML
2. • Why Use Perl with XML?
   • XML Is Simple with XML::Simple
   • XML Processors
   • A Myriad of Modules
   • Keep in Mind ...
   • XML Gotchas
3. An XML Recap
4. • A Brief History of XML
   • Markup, Elements, and Structure
   • Namespaces
   • Spacing
   • Entities
   • Unicode, Character Sets, and Encodings
   • The XML Declaration
   • Processing Instructions and Other Markup
   • Free-Form XML and Well-Formed Documents
   • Declaring Elements and Attributes
   • Schemas
   • Transformations
5. XML Basics: Reading and Writing
6. • XML Parsers
   • XML::Parser
   • Stream-Based Versus Tree-Based Processing
   • Putting Parsers to Work
   • XML::LibXML
   • XML::XPath
   • Document Validation
   • XML::Writer
   • Character Sets and Encodings
7. Event Streams
8. • Working with Streams
   • Events and Handlers
   • The Parser as Commodity
   • Stream Applications
   • XML::PYX
   • XML::Parser
9. SAX
10. • SAX Event Handlers
    • DTD Handlers
    • External Entity Resolution
    • Drivers for Non-XML Sources
    • A Handler Base Class
    • XML::Handler::YAWriter as a Base Handler Class
    • XML::SAX: The Second Generation
11. Tree Processing
12. • XML Trees
    • XML::Simple
    • XML::Parser's Tree Mode
    • XML::SimpleObject
    • XML::TreeBuilder
    • XML::Grove
13. DOM
14. • DOM and Perl
    • DOM Class Interface Reference
    • XML::DOM
    • XML::LibXML
15. Beyond Trees: XPath, XSLT, and More
16. • Tree Climbers
    • XPath
    • XSLT
    • Optimized Tree Processing
17. RSS, SOAP, and Other XML Applications
18. • XML Modules
    • XML::RSS
    • XML Programming Tools
    • SOAP::Lite
19. Coding Strategies
20. • Perl and XML Namespaces
    • Subclassing
    • Converting XML to HTML with XSLT
    • A Comics Index

Index

You may also want to check out Erik T. Ray's home page, Jason McIntosh's home page, or O'Reilly's page for the book. You can purchase Perl &amp XML from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Pearl is for fags!

[This_Is_ASDF]

dAFSdF Dd aSd..aFsfssaf af.s.S.ffFaASS aa SdSDAS.FDdFd..SadDSsfdsA..s .saDAFDa Fa d.Ssa dddaAAd.adFfFa a.s.SdA ..fSaAad. fAsD fs S. ddS sdFF.dFFFSFfFfffFa DSF.aSFD.afffDfdSAdSAFD.Sa sa FDaFSd D.f.dFfasDF.sA .dAD .. A.fADaFs..DFdAf .adas.SdsdaDfss.aASDD aS D FAFdSaSS SdF.SaDasasfDDdS Adad.a.. AsafDFFSa SDSa.DA.DFAffFfD.fDFD s.a.FFAF fDsfFa.D..fd fDsddadsDAsD sDsssDa aFAsSSds.S FaFsadd.DAS SfD.D .sDaSaFAf. sA sAA .FfFAdddDaf SfSff f.DdAF.ad DSADsfffFAsaFDSfAaFa ssfA.f sAaFfASA..aDSfDSsAaSAaFsddS.sa dD afdFafDaaf .dD dAd fFSaF.ddfsFf dd AsDADsS.FsfffD.FSDa F FsSFAds..SaS ..aF.fs F.SDDfDsddsAa.a asfD ssfafdsDASA ddsDd sSADFA.dDfS D.DddsSfadsASAaaf SSadAF.AaSaFfDFdsaAFAAaDfFdfaDDDS.ss.aF.FFafDaS.ds DD.DSdDsAFF ASASF FFfFDAd AaADfdDdsf . s.AD sddsSdadd.D fASs afsdDD.FsaDSasadAs.DsfsdaSFD .d A.sdF.SaS a. A SSf..Adsfa..sf AFADffF.AAfFSaffSsFDaAssafaa A d ... .FsSf.ff SsASsDdd.dFsd DFSfDDdfDdAfDSFsfS afAFAa..Fad .asdaaSf.aFfFDfsaaAafsFasD.safA. F S.d.afaffD. ..s. daSA.ASss fDdDff.d ..fFfd.A f. .AADf.aDdDd.aAa sD.fSdsdAf.sFFDaAdD.s.SfSF SSDdD saaS fDf DdsD.ASF.AAdsA..sSdsaAfds.DSFdaS ffS.a FAsd.DfFa.dfsFD sSfFAAasdS FASdAdS.sffsAdS. SaD fD.aaddS.afAAFDsDaSa sfad.Sa.fA fS fs.sa. ASdA.sDD ss.sfFD .fsfFD.fFF aaFSFdfFAaA.dSFAdFfSDFDdSSd.DafDdfAsDF. sS fA FDffAas ADaDF..f. S AAASaSdS..d.SAAfFSDfSadS.faFDSAd aaSFA . SFfdfSdd Da .SA S dAsSsfDDsdsaF.asf FAFddaSfSsaAD daaff.a ff d AfFssfsAFsff.DA .SDdsasfDDSf.sa ssFS f DDaD AfaDd..fadD..AdaFfA.SASfadaD DfasSDADFF.aDFafsafSDfddsAffFdFAFaFS.ffD fDsf.S dad.AD S .sdfsFsfF.d Asaasffaaaddd D.FA DFSaaS fDAFsa.fadS fFSDaFs.FsS FAasA.DaSdF.AadDdFsDD.D.FF.FaAdad fDfaasAFaaa DAfs dasfaa Fddad AF aF dA dDADAddFSSaa.sdS. FdFdDFSDDa. A ddf.SAD f. aSaddF fsss.aaadADS.s.FDSAss FADSS.s fSDS.DSa.aDSSFDDSSAfDS.DdS aDA asdFasAdaDsS .AfAssaaDaFsS s .FSddAdfdDf.asAaS.D.dF..F.fSfSa .SS s.Fa .aAAasSadFF .Ff .sDADSd dAAaAd.DDSFsdafdFD SfFa .D.DAsfDFa.AdsfdDffdfFSsSa.s.sAa. .SFd SAf D Ds a Fff SsAA SS.SDAS faadAfFAaASSDf aFaFsAfAss assFADFAsSa.sd .as fdAsfdSaS.SFaFSDA SaAAf.sAa .SD fa.SSa AFdFSFAf asDDFaF.DFf.DdAad FaSdSASSf sDsfaFd.asaFsSDFFdsfF.fA sddDD.s a DFDSFaFSs AdA.fFF fAaA.f SdAfdaaa.Fa.SDds F .F s.SFa.fSfF.AasDs.FdSDA.f..D.DfAa s. s fS ddDSsFAssfaS DAfFdDfAfD FaasS AFfsdd.AA SfsdaSAs. SFsaFsd.FFSFdad .FsAS SFSfAD d adDdasSs. ..S. dadfSF.dFSDfAfA.A.D..aAdsadaSfS. F aF Fd dDD..f.F aFaA.a.sFdFDSF F.FfDaDs.Sfas FSSSSsDFd.SA. fDFdFFDSa .sddd Sadf.FSFS.DdSFF.FFsSFa F d.S AA DaADS fAfDfdFfaFSS.Ds.fDsdfADadSaDfDsF DSF.Sf.S.DASaAdDSSfd fSa fSfD . d.fFd A fdd D sSsSFDa .S.AsSaddddDfSsaaDdfsaD FasFDf Dsf d S .F dADdD aASaa afdaFS..dfA FsaDd ..dfSSDD S.Sa..AsDfaFA f. SdfFSdDaDSD fsd DAAFaDDfDD.fdaDFdaDs SssdFFDsasaD.aDS.ffS .F S..DFas fA. fFAAdFfsFdDaAdSssDFFSDD .aadDsSda FddffdDd A sSFa FFfAd D DASADS.DafdfFaAdAsAssAF.ffSDFSdAsaaaFdFFDasAaFaDsA sff. FdfSa.aDadaaa aFss..f..sdS D.fdFDASa S.SF.SFA.FDaDFAFDFaAdFADdAD.sDf.S..FDDfSAdF aS .SSA.SdFFDADadd.sfFsfDSs .dasFSf daA. .s..f sdADdSas sAfADDffdaD DSFsF.fDdDaS Dad.sSfFdFA.daf DDsSAA SFsaAsF.sFsa.Df.sdSdSSAaA fs.FDDSFDfdA fADASA.AFffs..SsDs adAFasS.DaAsfd...SaS faA s AFAs..SD.aA.DSSFsF.d.A SdDSDsDsFSFaDFSS.SsFA.SSsDAASfadA.FdfFSsSSsf a.SFdS dfaAaDdFadfA faDsFFD ddsdsDdSfSaFFDaF..F dSFDFA.FfS DsA. daaaaFsDs..a.f DfsDFdAfsdsd.dS S.S.. a.AsaDdffdFDsSs.sds SaDfSAdd f.S SD Sd..SDFDAdSD DssFaSSSa.aAFDa SSaaSdSAd s dasaf a aSddDdDAs.aaSdad ...AafDa . F.aaFddASdsFsfaDDds ssfSfFSSfAdfDdSASFaddfd FdfFADdFFDDfAf.aFsSAAddsdASAFF..f DassasFDAfaSSsFdFA f.SFAsFAd.aDSaaDfdDaDsffDSf.S.A.FsDAfFaDDf SAAAF.f.SS sAaDSSFsSFdAfDfAAsFsDSFd DDfffDDF.S S A da.DDA SASAs .AdDsDaaSsadAFSfdafs.dSSD sfs .sssadsdADfAasAFSDs.adf.FafsADDDa.Fafs F.aAsfas..daaDf.DS .ffFafDsAsddsfdD A.S .a sD.aAASSsa sAd fADASdDAD AfFSf Dsf.FsD d.FAAddaDsASfdsaFFAS .dfdDddFdSdsSaF.dFFAA F.F.DS AfADS.AssAA.aSSdDDSDAsfd.daaaFDAs Aa afDDFDD fsfaDsDFSsaFfaad.SA fDaAaDdF dADfF.ss..Da.SSdFFsSAD.fD AAD .s.. .aAssDFdFSFaAF sAssa.ASS dAAsSaa.DfaSd AadDAdf.aDaaSDF as.sFs .sD.Ds dF .f.FfSaA a F afFaD .FfFDA .fFFFD.sS.Fa.d.f...D.SfaSSFffADdaDfFDdsff.Af d FfA.dSDASfsD.AdF.dFdaA saadAfSdf.DAs dFdFd...s.FADfA .F .fd . F.ffd.DfdAAfS DS dfDaaDaSSfFsf s FSFDAs.fFf. dA. sF sDD. aFDA a.dFaafssSdSSSFfDA SsDfF....FSfFFSSFFdssFfFSaFaDfSAAS.fAa .fDDsAS.fFaDFSAAFfAD.sf D . SFA.FAdfss.sfS.sf .FsD.fafdSA.dfDF DfSfS.dDdaF AfAA dA. a aAfAadf aSdfdsDs ..aS AssaSdSDS. s ASDsSA s.DaasssfDSsFDfDs. aFas DDf.AFAFDdF.S.ssF. DFD ..a..af FdD.aSSFAa.DSaFa.. FDd Fs FaSfSSA DDdAS.SDS D Sf.SdfasSSsFA Assss.fSDd s.sAAasSSA.DSDf.SFAfdDSAFsfAfF.S.dd dAs.ddSsasaFdSfSA.ffaSFAS.dAsSa fsAAffSA .fFAFSaD.ADSffd DFAfa.Sf sF.a .. FsSAasAFSasaDsDaf.FSAs Asa.aaASaS ADDdDfdFA.sfs d.a.sD dDAADsfDDFASAD sd SsFsAdA AADd.d.AD.SaFAaA SAaDD Aad.AD dds.SssDFaSSfDsfdDs.DaSdSDSD fsSDAFfSDAfASd.sdDa.fSaSdSsFD.dadfDA.ddF.DfSsd.fs. DF AafSsaSfdaSsAA DSAS.fD AdA D faDFSFF fs .daSF.dSS .Aa FDsDdDddSsaSsA. .a.sDDssA.DDSDfSASf. Fsd.f.aFFAa.SfFASssA.F Fsafa DSfsDA.SdsDFAD sFA.DAfFFfsF.S fffFSa FFF.DDS fafa.dA aA. S.dd DDA FsdF.fSFadsaAssaFAaS SdAFSdF Dd aSd..aFsfssaf af.s.S.ffFaASS aa SdSDAS.FDdFd..SadDSsfdsA..s .saDAFDa Fa d.Ssa dddaAAd.adFfFa a.s.SdA ..fSaAad. fAsD fs S. ddS sdFF.dFFFSFfFfffFa DSF.aSFD.afffDfdSAdSAFD.Sa sa FDaFSd D.f.dFfasDF.sA .dAD .. A.fADaFs..DFdAf .adas.SdsdaDfss.aASDD aS D FAFdSaSS SdF.SaDasasfDDdS Adad.a.. AsafDFFSa SDSa.DA.DFAffFfD.fDFD s.a.FFAF fDsfFa.D..fd fDsddadsDAsD sDsssDa aFAsSSds.S FaFsadd.DAS SfD.D .sDaSaFAf. sA sAA .FfFAdddDaf SfSff f.DdAF.ad DSADsfffFAsaFDSfAaFa ssfA.f sAaFfASA..aDSfDSsAaSAaFsddS.sa dD afdFafDaaf .dD dAd fFSaF.ddfsFf dd AsDADsS.FsfffD.FSDa F FsSFAds..SaS ..aF.fs F.SDDfDsddsAa.a asfD ssfafdsDASA ddsDd sSADFA.dDfS D.DddsSfadsASAaaf SSadAF.AaSaFfDFdsaAFAAaDfFdfaDDDS.ss.aF.FFafDaS.ds DD.DSdDsAFF ASASF FFfFDAd AaADfdDdsf . s.AD sddsSdadd.D fASs afsdDD.FsaDSasadAs.DsfsdaSFD .d A.sdF.SaS a. A SSf..Adsfa..sf AFADffF.AAfFSaffSsFDaAssafaa A d ... .FsSf.ff SsASsDdd.dFsd DFSfDDdfDdAfDSFsfS afAFAa..Fad .asdaaSf.aFfFDfsaaAafsFasD.safA. F S.d.afaffD. ..s. daSA.ASss fDdDff.d ..fFfd.A f. .AADf.aDdDd.aAa sD.fSdsdAf.sFFDaAdD.s.SfSF SSDdD saaS fDf DdsD.ASF.AAdsA..sSdsaAfds.DSFdaS ffS.a FAsd.DfFa.dfsFD sSfFAAasdS FASdAdS.sffsAdS. SaD fD.aaddS.afAAFDsDaSa sfad.Sa.fA fS fs.sa. ASdA.sDD ss.sfFD .fsfFD.fFF aaFSFdfFAaA.dSFAdFfSDFDdSSd.DafDdfAsDF. sS fA FDffAas ADaDF..f. S AAASaSdS..d.SAAfFSDfSadS.faFDSAd aaSFA . SFfdfSdd Da .SA S dAsSsfDDsdsaF.asf FAFddaSfSsaAD daaff.a ff d AfFssfsAFsff.DA .SDdsasfDDSf.sa ssFS f DDaD AfaDd..fadD..AdaFfA.SASfadaD DfasSDADFF.aDFafsafSDfddsAffFdFAFaFS.ffD fDsf.S dad.AD S .sdfsFsfF.d Asaasffaaaddd D.FA DFSaaS fDAFsa.fadS fFSDaFs.FsS FAasA.DaSdF.AadDdFsDD.D.FF.FaAdad fDfaasAFaaa DAfs dasfaa Fddad AF aF dA dDADAddFSSaa.sdS. FdFdDFSDDa. A ddf.SAD f. aSaddF fsss.aaadADS.s.FDSAss FADSS.s fSDS.DSa.aDSSFDDSSAfDS.DdS aDA asdFasAdaDsS .AfAssaaDaFsS s .FSddAdfdDf.asAaS.D.dF..F.fSfSa .SS s.Fa .aAAasSadFF .Ff .sDADSd dAAaAd.DDSFsdafdFD SfFa .D.DAsfDFa.AdsfdDffdfFSsSa.s.sAa. .SFd SAf D Ds a Fff SsAA SS.SDAS faadAfFAaASSDf aFaFsAfAss assFADFAsSa.sd .as fdAsfdSaS.SFaFSDA SaAAf.sAa .SD fa.SSa AFdFSFAf asDDFaF.DFf.DdAad FaSdSASSf sDsfaFd.asaFsSDFFdsfF.fA sddDD.s a DFDSFaFSs AdA.fFF fAaA.f SdAfdaaa.Fa.SDds F .F s.SFa.fSfF.AasDs.FdSDA.f..D.DfAa s. s fS ddDSsFAssfaS DAfFdDfAfD FaasS AFfsdd.AA SfsdaSAs. SFsaFsd.FFSFdad .FsAS SFSfAD d adDdasSs. ..S. dadfSF.dFSDfAfA.A.D..aAdsadaSfS. F aF Fd dDD..f.F aFaA.a.sFdFDSF F.FfDaDs.Sfas FSSSSsDFd.SA. fDFdFFDSa .sddd Sadf.FSFS.DdSFF.FFsSFa F d.S AA DaADS fAfDfdFfaFSS.Ds.fDsdfADadSaDfDsF DSF.Sf.S.DASaAdDSSfd fSa fSfD . d.fFd A fdd D sSsSFDa .S.AsSaddddDfSsaaDdfsaD FasFDf Dsf d S .F dADdD aASaa afdaFS..dfA FsaDd ..dfSSDD S.Sa..AsDfaFA f. SdfFSdDaDSD fsd DAAFaDDfDD.fdaDFdaDs SssdFFDsasaD.aDS.ffS .F S..DFas fA. fFAAdFfsFdDaAdSssDFFSDD .aadDsSda FddffdDd A sSFa FFfAd D DASADS.DafdfFaAdAsAssAF.ffSDFSdAsaaaFdFFDasAaFaDsA sff. FdfSa.aDadaaa aFss..f..sdS D.fdFDASa S.SF.SFA.FDaDFAFDFaAdFADdAD.sDf.S..FDDfSAdF aS .SSA.SdFFDADadd.sfFsfDSs .dasFSf daA. .s..f sdADdSas sAfADDffdaD DSFsF.fDdDaS Dad.sSfFdFA.daf DDsSAA SFsaAsF.sFsa.Df.sdSdSSAaA fs.FDDSFDfdA fADASA.AFffs..SsDs adAFasS.DaAsfd...SaS faA s AFAs..SD.aA.DSSFsF.d.A SdDSDsDsFSFaDFSS.SsFA.SSsDAASfadA.FdfFSsSSsf a.SFdS dfaAaDdFadfA faDsFFD ddsdsDdSfSaFFDaF..F dSFDFA.FfS DsA. daaaaFsDs..a.f DfsDFdAfsdsd.dS S.S.. a.AsaDdffdFDsSs.sds SaDfSAdd f.S SD Sd..SDFDAdSD DssFaSSSa.aAFDa SSaaSdSAd s dasaf a aSddDdDAs.aaSdad ...AafDa . F.aaFddASdsFsfaDDds ssfSfFSSfAdfDdSASFaddfd FdfFADdFFDDfAf.aFsSAAddsdASAFF..f DassasFDAfaSSsFdFA f.SFAsFAd.aDSaaDfdDaDsffDSf.S.A.FsDAfFaDDf SAAAF.f.SS sAaDSSFsSFdAfDfAAsFsDSFd DDfffDDF.S S A da.DDA SASAs .AdDsDaaSsadAFSfdafs.dSSD sfs .sssadsdADfAasAFSDs.adf.FafsADDDa.Fafs F.aAsfas..daaDf.DS .ffFafDsAsddsfdD A.S .a sD.aAASSsa sAd fADASdDAD AfFSf Dsf.FsD d.FAAddaDsASfdsaFFAS .dfdDddFdSdsSaF.dFFAA F.F.DS AfADS.AssAA.aSSdDDSDAsfd.daaaFDAs Aa afDDFDD fsfaDsDFSsaFfaad.SA fDaAaDdF dADfF.ss..Da.SSdFFsSAD.fD AAD .s.. .aAssDFdFSFaAF sAssa.ASS dAAsSaa.DfaSd AadDAdf.aDaaSDF as.sFs .sD.Ds dF .f.FfSaA a F afFaD .FfFDA .fFFFD.sS.Fa.d.f...D.SfaSSFffADdaDfFDdsff.Af d FfA.dSDASfsD.AdF.dFdaA saadAfSdf.DAs dFdFd...s.FADfA .F .fd . F.ffd.DfdAAfS DS dfDaaDaSSfFsf s FSFDAs.fFf. dA. sF sDD. aFDA a.dFaafssSdSSSFfDA SsDfF....FSfFFSSFFdssFfFSaFaDfSAAS.fAa .fDDsAS.fFaDFSAAFfAD.sf D . SFA.FAdfss.sfS.sf .FsD.fafdSA.dfDF DfSfS.dDdaF AfAA dA. a aAfAadf aSdfdsDs ..aS AssaSdSDS. s ASDsSA s.DaasssfDSsFDfDs. aFas DDf.AFAFDdF.S.ssF. DFD ..a..af FdD.aSSFAa.DSaFa.. FDd Fs FaSfSSA DDdAS.SDS D Sf.SdfasSSsFA Assss.fSDd s.sAAasSSA.DSDf.SFAfdDSAFsfAfF.S.dd dAs.ddSsasaFdSfSA.ffaSFAS.dAsSa fsAAffSA .fFAFSaD.ADSffd DFAfa.Sf sF.a .. FsSAasAFSasaDsDaf.FSAs Asa.aaASaS ADDdDfdFA.sfs d.a.sD dDAADsfDDFASAD sd SsFsAdA AADd.d.AD.SaFAaA SAaDD Aad.AD dds.SssDFaSSfDsfdDs.DaSdSDSD fsSDAFfSDAfASd.sdDa.fSaSdSsFD.dadfDA.ddF.DfSsd.fs. DF AafSsaSfdaSsAA DSAS.fD AdA D faDFSFF fs .daSF.dSS .Aa FDsDdDddSsaSsA. .a.sDDssA.DDSDfSASf. Fsd.f.aFFAa.SfFASssA.F Fsafa DSfsDA.SdsDFAD sFA.DAfFFfsF.S fffFSa FFF.DDS fafa.dA aA. S.dd DDA FsdF.fSFadsaAssaFAaS SdAFSdF Dd aSd..aFsfssaf af.s.S.ffFaASS aa SdSDAS.FDdFd..SadDSsfdsA..s .saDAFDa Fa d.Ssa dddaAAd.adFfFa a.s.SdA ..fSaAad. fAsD fs S. ddS sdFF.dFFFSFfFfffFa DSF.aSFD.afffDfdSAdSAFD.Sa sa FDaFSd D.f.dFfasDF.sA .dAD .. A.fADaFs..DFdAf .adas.SdsdaDfss.aASDD aS D FAFdSaSS SdF.SaDasasfDDdS Adad.a.. AsafDFFSa SDSa.DA.DFAffFfD.fDFD s.a.FFAF fDsfFa.D..fd fDsddadsDAsD sDsssDa aFAsSSds.S FaFsadd.DAS SfD.D .sDaSaFAf. sA sAA .FfFAdddDaf SfSff f.DdAF.ad DSADsfffFAsaFDSfAaFa ssfA.f sAaFfASA..aDSfDSsAaSAaFsddS.sa dD afdFafDaaf .dD dAd fFSaF.ddfsFf dd AsDADsS.FsfffD.FSDa F FsSFAds..SaS ..aF.fs F.SDDfDsddsAa.a asfD ssfafdsDASA ddsDd sSADFA.dDfS D.DddsSfadsASAaaf SSadAF.AaSaFfDFdsaAFAAaDfFdfaDDDS.ss.aF.FFafDaS.ds DD.DSdDsAFF ASASF FFfFDAd AaADfdDdsf . s.AD sddsSdadd.D fASs afsdDD.FsaDSasadAs.DsfsdaSFD .d A.sdF.SaS a. A SSf..Adsfa..sf AFADffF.AAfFSaffSsFDaAssafaa A d ... .FsSf.ff SsASsDdd.dFsd DFSfDDdfDdAfDSFsfS afAFAa..Fad .asdaaSf.aFfFDfsaaAafsFasD.safA. F S.d.afaffD. ..s. daSA.ASss fDdDff.d ..fFfd.A f. .AADf.aDdDd.aAa sD.fSdsdAf.sFFDaAdD.s.SfSF SSDdD saaS fDf DdsD.ASF.AAdsA..sSdsaAfds.DSFdaS ffS.a FAsd.DfFa.dfsFD sSfFAAasdS FASdAdS.sffsAdS. SaD fD.aaddS.afAAFDsDaSa sfad.Sa.fA fS fs.sa. ASdA.sDD ss.sfFD .fsfFD.fFF aaFSFdfFAaA.dSFAdFfSDFDdSSd.DafDdfAsDF. sS fA FDffAas ADaDF..f. S AAASaSdS..d.SAAfFSDfSadS.faFDSAd aaSFA . SFfdfSdd Da .SA S dAsSsfDDsdsaF.asf FAFddaSfSsaAD daaff.a ff d AfFssfsAFsff.DA .SDdsasfDDSf.sa ssFS f DDaD AfaDd..fadD..AdaFfA.SASfadaD DfasSDADFF.aDFafsafSDfddsAffFdFAFaFS.ffD fDsf.S dad.AD S .sdfsFsfF.d Asaasffaaaddd D.FA DFSaaS fDAFsa.fadS fFSDaFs.FsS FAasA.DaSdF.AadDdFsDD.D.FF.FaAdad fDfaasAFaaa DAfs dasfaa Fddad AF aF dA dDADAddFSSaa.sdS. FdFdDFSDDa. A ddf.SAD f. aSaddF fsss.aaadADS.s.FDSAss FADSS.s fSDS.DSa.aDSSFDDSSAfDS.DdS aDA asdFasAdaDsS .AfAssaaDaFsS s .FSddAdfdDf.asAaS.D.dF..F.fSfSa .SS s.Fa .aAAasSadFF .Ff .sDADSd dAAaAd.DDSFsdafdFD SfFa .D.DAsfDFa.AdsfdDffdfFSsSa.s.sAa. .SFd SAf D Ds a Fff SsAA SS.SDAS faadAfFAaASSDf aFaFsAfAss assFADFAsSa.sd .as fdAsfdSaS.SFaFSDA SaAAf.sAa .SD fa.SSa AFdFSFAf asDDFaF.DFf.DdAad FaSdSASSf sDsfaFd.asaFsSDFFdsfF.fA sddDD.s a DFDSFaFSs AdA.fFF fAaA.f SdAfdaaa.Fa.SDds F .F s.SFa.fSfF.AasDs.FdSDA.f..D.DfAa s. s fS ddDSsF

a Perl book? buy it for slashdev

[Sexual Asspussy]

fp

Perl & Widening

[Klerck]

.I.like.wide.pages.I.wish.all.pages.could.be.as.w .ide.as.this.dont.you.wide.pages.are.much.cooler.t .han.those.narrow.pages.you.are.used.to.reading.be .cause.you.dont.have.to.worry.about.the.lameness.f .ilter.telling.you.that.you.don't.have.enough.char .aters.per.line.that.really.sucks.when.that.happen .s.and.you.have.to.put.some.lame.lameness.filter.d .efeater.text.in.there.i.wonder.how.many.people.wi .ll.read.this.whole.comment.I.certainly.hope.it.do .esnt.annoy.too.many.people.This.is.just.the.begin .ning.because.PAGE.WIDENING.IS.BACKabcdefghijklmno .pI.like.wide.pages.I.wish.all.pages.could.be.as.w .ide.as.this.dont.you.wide.pages.are.much.cooler.t .han.those.narrow.pages.you.are.used.to.reading.be .cause.you.dont.have.to.worry.about.the.lameness.f .ilter.telling.you.that.you.don't.have.enough.char .aters.per.line.that.really.sucks.when.that.happen .s.and.you.have.to.put.some.lame.lameness.filter.d .efeater.text.in.there.i.wonder.how.many.people.wi .ll.read.this.whole.comment.I.certainly.hope.it.do .esnt.annoy.too.many.people.This.is.just.the.begin .ning.because.PAGE.WIDENING.IS.BACKabcdefghijklmno .pI.like.wide.pages.I.wish.all.pages.could.be.as.w .ide.as.this.dont.you.wide.pages.are.much.cooler.t .han.those.narrow.pages.you.are.used.to.reading.be .cause.you.dont.have.to.worry.about.the.lameness.f .ilter.telling.you.that.you.don't.have.enough.char .aters.per.line.that.really.sucks.when.that.happen .s.and.you.have.to.put.some.lame.lameness.filter.d .efeater.text.in.there.i.wonder.how.many.people.wi .ll.read.this.whole.comment.I.certainly.hope.it.do .esnt.annoy.too.many.people.This.is.just.the.begin .ning.because.PAGE.WIDENING.IS.BACKabcdefghijklmno .pI.like.wide.pages.I.wish.all.pages.could.be.as.w .ide.as.this.dont.you.wide.pages.are.much.cooler.t .han.those.narrow.pages.you.are.used.to.reading.be .cause.you.dont.have.to.worry.about.the.lameness.f .ilter.telling.you.that.you.don't.have.enough.char .aters.per.line.that.really.sucks.when.that.happen .s.and.you.have.to.put.some.lame.lameness.filter.d .efeater.text.in.there.i.wonder.how.many.people.wi .ll.read.this.whole.comment.I.certainly.hope.it.do .esnt.annoy.too.many.people.This.is.just.the.begin .ning.because.PAGE.WIDENING.IS.BACKabcdefghijklmno .pI.like.wide.pages.I.wish.all.pages.could.be.as.w .ide.as.this.dont.you.wide.pages.are.much.cooler.t .han.those.narrow.pages.you.are.used.to.reading.be .cause.you.dont.have.to.worry.about.the.lameness.f .ilter.telling.you.that.you.don't.have.enough.char .aters.per.line.that.really.sucks.when.that.happen .s.and.you.have.to.put.some.lame.lameness.filter.d .efeater.text.in.there.i.wonder.how.many.people.wi .ll.read.this.whole.comment.I.certainly.hope.it.do .esnt.annoy.too.many.people.This.is.just.the.begin .ning.because.PAGE.WIDENING.IS.BACKabcdefghijklmno .pI.like.wide.pages.I.wish.all.pages.could.be.as.w .ide.as.this.dont.you.wide.pages.are.much.cooler.t .han.those.narrow.pages.you.are.used.to.reading.be .cause.you.dont.have.to.worry.about.the.lameness.f .ilter.telling.you.that.you.don't.have.enough.char .aters.per.line.that.really.sucks.when.that.happen .s.and.you.have.to.put.some.lame.lameness.filter.d .efeater.text.in.there.i.wonder.how.many.people.wi .ll.read.this.whole.comment.I.certainly.hope.it.do .esnt.annoy.too.many.people.This.is.just.the.begin .ning.because.PAGE.WIDENING.IS.BACKabcdefghijklmno .pI.like.wide.pages.I.wish.all.pages.could.be.as.w .ide.as.this.dont.you.wide.pages.are.much.cooler.t .han.those.narrow.pages.you.are.used.to.reading.be .cause.you.dont.have.to.worry.about.the.lameness.f .ilter.telling.you.that.you.don't.have.enough.char .aters.per.line.that.really.sucks.when.that.happen .s.and.you.have.to.put.some.lame.lameness.filter.d .efeater.text.in.there.i.wonder.how.many.people.wi .ll.read.this.whole.comment.I.certainly.hope.it.do .esnt.annoy.too.many.people.This.is.just.the.begin .ning.because.PAGE.WIDENING.IS.BACKabcdefghijklmno .pI.like.wide.pages.I.wish.all.pages.could.be.as.w .ide.as.this.dont.you.wide.pages.are.much.cooler.t .han.those.narrow.pages.you.are.used.to.reading.be .cause.you.dont.have.to.worry.about.the.lameness.f .ilter.telling.you.that.you.don't.have.enough.char .aters.per.line.that.really.sucks.when.that.happen .s.and.you.have.to.put.some.lame.lameness.filter.d .efeater.text.in.there.i.wonder.how.many.people.wi .ll.read.this.whole.comment.I.certainly.hope.it.do .esnt.annoy.too.many.people.This.is.just.the.begin .ning.because.PAGE.WIDENING.IS.BACKabcdefghijklmno .pI.like.wide.pages.I.wish.all.pages.could.be.as.w .ide.as.this.dont.you.wide.pages.are.much.cooler.t .han.those.narrow.pages.you.are.used.to.reading.be .cause.you.dont.have.to.worry.about.the.lameness.f .ilter.telling.you.that.you.don't.have.enough.char .aters.per.line.that.really.sucks.when.that.happen .s.and.you.have.to.put.some.lame.lameness.filter.d .efeater.text.in.there.i.wonder.how.many.people.wi .ll.read.this.whole.comment.I.certainly.hope.it.do .esnt.annoy.too.many.people.This.is.just.the.begin .ning.because.PAGE.WIDENING.IS.BACK

Gene Kan, Gnutella creator, dead at 25

[Anonymous Coward]

I just heard some sad news on talk radio -
Gnutella creator Gene Kan was found dead in his California home this morning. There weren't any more details. I'm sure everyone in the Slashdot community will miss him - even if you didn't enjoy his work, there's no denying his contributions to popular culture. Truly an American icon.

Re:Gene Kan, Gnutella creator, dead at 25

[Anonymous Coward]

Too controversial since MS renewed their marketing plan with certain "provisions". Oh well, they have to make money somehow. I wonder what MS will do when they realize that these guys are serving up single pixle graphics" as "ads".

micr5001en.gif - micr5017en.gif
and
micr6001en.gif - micr6003en.gif

Guess when a company is desperate to pay the bills they will do anything to make a buck.
R-W-S

First XML app

[Anonymous Coward]

#! /usr/bin/perl

print

EOF

That would have been useful...

[Anonymous Coward]

in October 2000 when Perl was as its peak. Now that Perl is dying where's the interest?

Re:Gene Kan, Gnutella creator, dead at 25 [OT]

[Anonymous Coward]

Here's a kuro5hin story on it from two days ago, i suggest you look at it if this matters to you.

my opinion

[larry bagina]

I am a professional developer, working mostly with Perl. I work in the field of biology and bioinformatics, but have spent the last 8 years working as a web and database Internet developer. And, I own practically every O'Reilly Perl book ever published (not that I necessarily think they're all worth buying). So, now that you know where I'm coming from...

If you are preparing to do a serious amount of XML development, and you're in the process of determining a) which Perl XML modules on CPAN you want to use, and b) how to use them; and, you don't have a whole lot of time to spend tracking down the sometimes-hard-to-find documentation on these modules; then buying this book is a no-brainer. It covers all the major XML modules, how to use then and really helps you figure out when to use the different modules.

Even if you're not new to XML and Perl, this book would serve as an excellent refresher course on what XML tools are available out there for you... Maybe you haven't looked at your code in awhile, or want to update it to use a newer module from CPAN? Or, maybe you're looking for a better way to do it? Then, this book would definitely help you out.

While a fan of O'Reilly books in general, I'll be the first to admit some of them are more useful than others. I highly recommend this book, though, as it's actually useful, comprehensive and very well presented. I find myself cracking it open all the time, especially as my utilization of XML has grown more complicated. It has definitely earned its place in my Aqua Perl book collection.

First culinary post

[Anonymous Coward]

I like lobster.

XML, whatever

[Anonymous Coward]

sex with donkeys: it's not just for breakfast any more.

Speaking of fucking donkeys, I'd like to give Taco's mom a perl necklace.

Re:XML, whatever

[DonkeyHote]

...and a Donkey Punch!

The most important step to learning XML...

[Anonymous Coward]

... is not actually learning XML Learn HTML first; so you'll practice & develop a feel for it.

Re:The most important step to learning XML...

[JamesOfTheDesert]

Learn HTML first; so you'll practice & develop a feel for it.

Comparisons between HTML and XML are useful for those who already know HTML, but there are sufficient problems with HTML that, if both are new to you, then learning XML first is a beter route.

HTML allows various contructs that are not proper XML. Browsers will gladly accept unclosed meta, img, p, and br elements. Most HTML tools do not enforce the same requrements as an XML tool.

Worse, some browser can't handle certain markup; <br/> chokes certain versions of Navigator.

If you care to learn XML for some practical purpose, try learning XHTML. You'll learn about validation, well-formeness, and acquire a useful skill.

http://www.w3.org/TR/xhtml1/

If you can get your pages online, you can check them using the W3C html validation service:

http://validator.w3.org/

Re:The most important step to learning XML...

[King of the World]

isn't valid in X/HTML. They ask you to put a space there because dumb browsers parse the tag's name as "br/" and don't know what to do with it.

The problem is in Netscape 3 and lower. I'm not exactly sure what versions of IE were afficted but I believe it was 2 and lower.

Re:The most important step to learning XML...

[JamesOfTheDesert]

This is from the W3C XHTML spec:

4.6 Empty Elements

Empty elements must either have an end tag or the start tag must end with />. For instance, <br/> or <hr></hr>. See HTML Compatibility Guidelines for information on ways to ensure this is backward compatible with HTML 4 user agents.

CORRECT: terminated empty tags

<br/><hr/>

There is no mention or example of using a space after the element name.

Re:The most important step to learning XML...

[Anonymous Coward]

Argh... I was going after this tutorial.

I should pay more attention....

this is a waste of time

[neal n bob]

this is like learning to speak latin - both are dead languages spoken mainly by men who molest young boys.

Example of Valid XML (according to Perl :-)

[fastdecade]

I wonder if this conforms to the dtd
a bit of xml i wrote -- xml comments look something like this
-->

Where PERL went wrong

[DonkeyHote]

They used a camel instead of a Donkey, everyone knows that donkeys are more loveable!

XML sucks

[micromoog]

XML is a giant leap backwards. It makes us convert data from a binary format, to a terribly verbose text format, then back to a binary format for use. This leads to:

• conversion complexity
• conversion errors
• vast storage requirements
• vast bandwidth requirements

The only benefit AFAIK is that applications from different vendors can use it to "talk" to each other. However, the applications still have to understand the same set of XML tags to begin with, then must conform to this hideous standard with all of its verbosity. Said applications would have been better off using a proprietary (read: efficient) binary storage format in the first place.

Ban XML!

Re:XML sucks

[Anonymous Coward]

I have to agree, the first time I saw it I thought to myself... "why?"

sure it would be nice to have some standard that apps could talk to each other, especailly between various DBs, I cant see how this bloated apporach can be effective, you can easily triple the size of a document, and God forbid if it isnt "well-formed"

Re:XML sucks

[sporty]

Ok, i'll reply to this. I'm proly being trolled :P

Conversion complexity, granted. It does take a bit of work. But would you recomend describing each record with individual lines? That's a bigger pain than ever. What XML gives isn't just a structure for your data, but a language to describe it. It also allows for non-2d data. By this, we can have people with subsets of data, with subsets of different types. This is great, as now we can have a language that describes data in a logical manner and be completely portable.

Conversion errors, please be more spefic. If you convert to a comma delimited format, you are screwd if you do it wrong. If you do it straight to binary, you have to worry about how many bits represent any given data. Why do you think that pack has so many different switches for converting data?

Just because you use XML doesn't mean you must store data in XML form. Hell, it's stupid if you have gigs of data to use XML to relate it all. DB's dont' use xml except for expression of data back to the user/software it talks to (if asked for).

If you are worried about bandwidth, on a simplistic level, gzip it. Yes, compress it. Hell, do a gzip stream which is supported by many browsers.

If your program plans on sharing data, you'll want to use XML. If you never want to share your data, fine use binary. It's not terrible. But once you wanna share it between two machines or processes, now you have to worry about deciphering the binary format. THat is.. unless you work by yourself and have documentation on everything.

Re:XML sucks

[Trilaka]

Ok, granted it is generally bad form to respond to trolls, but this one reminded me of a good story that I thought I would share.

Problem: Given a document in Word format containing a table on which various operations must be performed, resulting in an HTML page with a consistent format.

Now, first of, simply saving the document as HTML from within word was far from sufficient. So, what to do? We tried various methods using Microsoft products to do the requisite transformations, all to no avail. We simply didn't have the control we needed.

Solution: Import the file into OpenOffice.org's Writer, save in OOo format (XML based), write a quick one-page perl script using XML::Twig (even though I had never examined OOo XML format prior to this exercise), and voila, problem solved.

This was a great example to me of the power of XML. Sure, XML is verbose, but remember, it is all ASCII text, and compressing ASCII text is basically a solved problem in computer science, so the verbosity needn't create much of a storage hit.

Horray for adoption of XML file formats!

Re:XML sucks

[JohnFluxx]

Wow!
The one other slashdotter that realises you don't have to actually store the data in XML form!

And I was beggining to feel lonely... ;)

Re:XML sucks

[sporty]

Of course. XML is mostly useful for sharing data outside the realm of one person. It's MUCH faster to store a C struct in binary form and reload it than parsing XML. No parsing.

Re:XML sucks

[mccalli]

Why is the parent modded as flamebait? It's a valid point of view, and completely accurate for many uses.

However, I'm not as 100% opposed as the poster above. Specifically, I have a minor SGML background as well as XML and so can see the uses a little better.

Basically, the data is nothing without the associated transform. I'm talking about the literal meaning of the word transform here - whether transformed into into memory structures within a program through parsing, or whether merely transformed into other document types via XSLT.

For example, I use XML as the format in which my servlet-based reports are generated. JAXP then handles transforming into my desired output format. The user wants a web pagea as their result? Fine - here's the XSLT stylesheet to transform into HTML. They wan't Excel? Well...almost but here's the XSLT to transform into .csv.

You get the idea. Automatic, reflex use of XML is over the top and unecessary. Use of XML where portable source data is transformed into one of a variety of options however is quite useful.

Cheers,
Ian

Re:XML sucks

[JohnFluxx]

Faster for the computer sure.
But what about later when you need to support
different languages, or change your struct,
or change to a different architecture?
And still need to make it backward compatible?

Re:XML sucks

[sporty]

Change in structure? No problem. What you do is use XSLT or rewrite stuff using DOM or SAX. SAX being the biggest hack, DOM being the biggest pain. XSLT being the quickest solution. XSLT would allow you to transform any single file. Write a quick bit of code to loop the transformation on all suplied files and poof, you are done.

Re:XML sucks

[JohnFluxx]

:)

Exactly! Easy in XML, but how would you do this if you saved the files as a dump of a C data object...

Re:XML sucks

[sporty]

Simple. you load up the data in one struct, create a new struct, do a 1-1 mapping and output the new one. Don't taunt the systems programmers ;)

Re:XML sucks

[JohnFluxx]

And if you forgot to indicate a version number?
Or forgot to indicate the language encoding
or endiness...

Re:XML sucks

[sporty]

The same could be said of XML. An XML document doesn't have to validate against a dtd.

As for language encoding.. and that silliness, you can do a binary->binary conversion. You just have to know the language you are using. Like int's are 32 bits, unsigned are 31 + the signed bit. Etc etc.. so it's not terrible. :)

Re:XML sucks

[JohnFluxx]

Sure, but how many people specify the size of an int, the endiness etc in the actual file when they save a binary file?

Re:XML sucks

[sporty]

Ah, but remember, in a controled environment, where source and everything is documented, it's not a "bad thing". Oracle works like this of course. Do they have problems migrating their binaries data format? Doubtfully.

Re:XML sucks

[JohnFluxx]

Oh definetly!
If you plan and document etc, anything you do will probably be good.
I was thinking more along the lines of a small hobbiest programmer, or the average company, where they knock out something quickly, then 6 months down the line run into problems because they forgot to specify the size of their ints in their file format, or what have you.
XML just allows the novice-to-medium programmer and company to make less mistakes at that stage.
Particulary early on where the data they are trying to save my vary a lot.

Re:XML sucks

[sporty]

Then are we agreeing on the same thing? :)

Note: added you as a friend. I'm glad slashdot actually added messaging when someone replies to you. Actually nice to have conversations.

Re:XML sucks

[JohnFluxx]

The messaging thing is pretty neat yeah..

I'm working on a load of xml apps, and although they use and rely on xml a lot, they hardly ever have anything in the xml format.
Everything is stored in databases, and database files, the data transfer is negotiated to find the optimin format, the xml schemas are turned into actual code, and so on.

However it does mean that I can plan and design it with xml in mind - meaning i get all the advantages of schemas etc, but without the disadvantages of verbosness, slowness, etc.

Re:XML sucks

[sporty]

Heh, wish where I worked was like that. We have stupid things going on such as our Database doing direct connections to 3rd party web services. We have about 2000 tables in our database. It's flippin' stupid.

Right...

[alexhmit01]

You realize that if I get an XML file, I can figure out what it is saying and decide what to do with it. With your ideal (binary) files, I need to reverse engineer the format.

With binary, I need permission to interoperate. With XML, I need a text editor (or print-out) and some common sense.

You worry all you want about the computer's efficiency. I use my machines to make my life easier. I don't jump through hoops to make the computer's life easier...

Taking troll bait,
Alex

Re:Right...

[jkroll]

With XML, I need a text editor (or print-out) and some common sense.

Actually you still need the same thing you would need with the binary format. You need the documentation as to what the tags mean. Try looking at XML produced by commercial software sometimes. Just because SAP calls the tag "ITEM" doesn't mean it refers to a part number or something you can pick up at the store. And looking at the schema or DTD probably won't help you figure out the tags mean either.

Finally parsing XML is easy when the document produced by an external system exactly mirrors your internal representation, unfortunately if you are interfacing XML documents with external systems this will almost never be the case.

Don't get me wrong, XML has its uses - just the exchange of data between disparate systems isn't one of them.

Re:Right...

[micromoog]

You're implying that XML was designed to make data more human-readable? Bollocks! That's what documentation is for!

So, other than making it easier to reverse-engineer a data format that you're not supposed to be reverse-engineering (complete with bugs that come in because you guessed wrongly that <co> means Country and not County), what other benefits are there?

Re:Right...

[simonj]

Finally parsing XML is easy when the document produced by an external system exactly mirrors your internal representation, unfortunately if you are interfacing XML documents with external systems this will almost never be the case.

This is true. It is also why XSLT (and other XML transformation languages before anyone flames about the shiteness of XSLT) were invented. Of course, you do still need the documentation to understand the XML to be able to write the stylesheet. If the design of the XML schema (or *shudder* DTD) is badly thought out and hard to understand, well, you can't really legislate for that with out taking the "extensible" bit out of XML.

Re:Right...

[Anonymous Coward]

More trolling: what if the XML you're looking at is actually a MIME64-encoded object?

<microsoft-proprietary-format>
MIME64-encoding begins here
</microsoft-proprietary-format>

Just because the tags are XML doesn't mean that the data is easy to read.

Re:Right...

[clearcache]

Actually, I for one am quite concerned about the computer's efficiency. When you have 10,000 concurrent users, those minute speed improvements will pay huge gains.

Re:Right...

[wobuzhudao]

Making data human-readalbe. No amount of documentation is going to help me read a binary file.

Why parse XML in the first place?

[SystemFork]

Parsing XML indeed. I mean seriously, have any of you ever actually tried to impliment XML parsing? It's an order of magnitude slower than accessing a database, ten zillion times slower than reading a flat file ASCII database, and a trillion times more expensive (well, I'm exaggerating a bit) than reading in a text file with nested variable=value pairs.

Interoperability is great and all, but I think XML is nothing but hype.

Programmers, hear my cry! Spend your precious hours working on your program interface, your error-checking, your overall design and modularity, don't spend time worrying about a scheme with a fancy name that saves data like this: value.

Don't mod me up or down, I just want to foster a discussion about this. I mean, as a standalone programmer using Perl for a majority of their web application products, what benefit does XML give you other than buzzword compliance?

----

Re:Why parse XML in the first place?

[SystemFork]

"Programmers, hear my cry! Spend your precious hours working on your program interface, your error- checking, your overall design and modularity, don't spend time worrying about a scheme with a fancy name that saves data like this: value."

Argh! Slashdot cut out my pseudo-tags, in my original post I meant <variable>value</variable>.

I bet I won't be the only one to make that mistake today. If you're posting XML, be sure to save the post as "Extrans (html tags to text)" instead of "Plain old text" or "HTML formatted" to save your braces from being truncated.

This has been a public service announcement.

Now I'm depressed, I'm going to go work on my latest server. At least I have some control there.
-----

Re:Why parse XML in the first place?

[eaeolian]

Having done some Java/XML work last year, then stumbling back into a homogenous Windows environment, I can honestly say I think XML has strengths and weaknesses.

Speed, however, is a primary problem, or at least it was when we were using XML to store/parse tens of thousands of elements for a Financial Services app in Java. It had the advantage of not being tied to a particular platform, and needing no database of any form distributed with it, and being read-compatible with some existing applications. So it was worth it to the client.

In my current environment, it makes no sense, other than "buzzword compliance".

So it's got it's uses, but it's not a magic bullet. Then again, I think Client/Server is a better solution than going web-based for a lot of things, so what do I know? :)

Re:Why parse XML in the first place?

[scott1853]

We just dumped XML for our primary storage format for an application we're about to release. We're still using it as a backup/restore format though.

The problem was that while our program will generate probably only a few K of data per day in binary format, once you translate that binary data to XML with descriptive tag names and attribute names, it would get to be 100K per day due to the number of attributes per record. After a couple months you may be looking at 10 megs or more. Load/save times were several minutes. We switched to the BDE (I know it sucks) and load times are instant due to being able to load records on demand instead of everything at once.

Re:Why parse XML in the first place?

[JohnFluxx]

The trouble is that people use it wrongly. (IMHO)

If it is done right, most of the time you should never have any actual XML text!

Store the data you are using in DOM, and manipulate it there. Store the data in DOM format on the disk, with a way to dump to XML if you have to (which you rarely will). Compile your Schemas, etc.

I'm also not sure why you imply it is costing time using XML - one of the ideas is that it is supposed to save time - and it does.
I can write schemas to validate the output and input, write XSL's to transform the data to anything, and so on.

Re:Why parse XML in the first place?

[midh]

I have spent my Junior and Senior years in college working with XML (as a personal project). I just graduated and I am still working with XML. I will agree that in some places XML is being used in ways it was never intended. That is why they call it extensible. It will fit almost anywhere but is not the best solution for most problems.

One good example of XML use is in Open Office. I believe the Open Office file format will end up being the most important contribution that Sun made in the office application arena.

Another good place to use XML is in cofiguration files. The advantages are obvious.

Parsing XML takes resources, so in most applications you should not do it in real time. An example of this is in a dynamic web environment. Try implementing Slashdot with a XML based backend. But with browsers becoming XML aware, you can offload this parsing to the browser.

The worst place to use XML IMHO is to describe logic. Some people have tried this - like XSP or JSP. There are some advantages to it but I think it ends up being a mess. XSLT got away with being a mess because it was one of few solutions to the problem of XML transformations.

An argument about the evils of XML is akin to saying Perl is a nasty language. A professor who taught Perl actually told me that. It is a nasty language but it solves some problems elegantly.
XML on the other hand is quite pretty and it solves several problems elegantly.

It is when you fall to the hype and use XML becaue you want to advertise it as a "feature" that it fails. XML is not a feature - it is a solution to certain problems.

I could care less if your program uses XML in some obscure place that I can't see. If you can give me a way to export my data to XML, I will be happy. I can write a config file as XML, I will be happy. But if you say, I use XML in this application to implement the Help feture which is only accessible through the Help button, I could care less.

P.S: I hate it when interesting stuff gets posted in the middle of the day when I am at work

Re:Why parse XML in the first place?

[Anonymous Coward]

Why not? If you have gazillion of distributed
applications, some common data interchange protocol is needed, xml fits this role, so
does soap, rss, rdf etc... Another big use
of xml comes into play when clean separation
of content from the presentation logic is needed.
Imagine a website with millions of article authors
all submitting xml content, easily parsable that
can be transformed into anything you like ( html, pdf, sgml, etc.. ) without any prior author interevention. Comlex website pipelines can also be created to aid in transformation process.

--
darkskies

Re:Why parse XML in the first place?

[Anonymous Coward]

>Parsing XML takes resources, so in most >applications you should not do it in real time.
>An example of this is in a dynamic web >environment. Try implementing Slashdot with a >XML based backend. But with browsers becoming >XML aware, you can offload this parsing to the >browser.

www.axkit.org

--
darkskies

Re:Why parse XML in the first place?

[The Pim]

Interoperability is great and all, but I think XML is nothing but hype.

Heck, let me give this my crack... :-)

Ok, obviously the biggest reason for XML's popularity is hype. That's just the way the industry works; it doesn't make XML good or bad.

There are a several legitimate technical benefits to XML, that might be persuasive in one context or another.

• It looks like HTML, so everyone intuitively "gets" it.
• It's textual (not binary)--but of course, many formats are textual.
• It's reasonably easy for humans to understand without a spec, provided the tag and attribute names are not obfuscated, and the relationships are relatively simple. Note this does not make it easy for programs to understand!
• You don't have to write your own parser. You don't even have to write a grammar--just throw in a tag and the corresponding code to read and write it. This advantage is not as big as some make it out to be: many languages have easy-to-use features for parsing, and those that don't can make use of easy-to-use parser-generator tools.
• There are lots of libraries and tools. Of course, this is self-reinforcing (tools -> popular -> more tools -> more popular -> ...).

Many XML proponents, including some in this thread, would add to this list that XML is a good data storage and/or interchange format. Some "insightfully" note that it is better for data interchange than data storage. This is the biggest delusion over XML: XML is a rotten format for data.

Remember what XML was back before the hype machine was in overdrive? It was a better HTML, and a simpler SGML. HTML and SGML have always been formats for documents, and XML was intended to be the same. XML is indeed a pretty good match for documents. (This is debated of course: documents are complex things, and modeling them is non-trivial. Embedded Markup Considered Harmful, by Ted Nelson, is a good introduction.)

But XML is a poor match for data. This is because an XML document is a tree, and most data are not hierarchical. Consider that the database industry abandoned hierarchical databases many years ago (ok, abandoned is a little strong: we still use LDAP). Hierarchical data formats force you to pick which relationships will define the hierarchy, and any other relationships have to be kluged in.

Take a simple example of the sort of thing people use XML for: address book entries. Say you start out with a person element (I'm not going to write out the examples in XML syntax because it's too painful on slashdot) containing a name element and an address element. Now, you realize that multiple people may live at the same address, and you don't want to duplicate the address (data formats should be normalized). You either have to turn things inside out, putting the person element inside the address element, or make person and address both top-level elements, and link them somehow. In the former case, you have chosen an awkward hierarchy, and have "used-up" your ability to group people. What if you want a different grouping in the future? In the latter case, you have given up a lot of simplicity and read/writability (since now names and their corresponding addresses are in different places) by forcing non-hierarchical data into a hierarchical format.

What is the solution? Well, I won't assert that it is the best data model that will ever exist, but the database industry has settled (roughly) on the relational model. So I think we should create a format describing relations, combined with the other advantages of XML: extensible, textual, readable, and most of all, standards-based. Yes, this would mean we would have to learn two technologies, one for documents and one for data. But the technology for data would be so much simpler--and as a bonus, integrate easily into our databases--that it would be a huge win overall. I don't have time to defend this model in depth. But think about it.

By the way, another example of the bad match between XML and data is the great debate over when you should use elements, and when you should use attributes. The fact that there is an arbitrary decision to be made shows that XML has degrees of complexity that only get in the way when you use it as a data format. (If you're going to use XML for data, at least have the decency to eschew attributes except for an id attribute.)

Re:Why parse XML in the first place?

[thogard]

You don't even get into its real uglyness...

If you have to parse a bad xml file you will get into two states, one requires an infinite amount of memory, the other infinite amount of memory.

how do you get these broken xml files? Either a closing tag went missing or the program that created them has a bug or your program has a bug or...

Dr Knuth wrote about these problems because TeX suffers from them too. His solution is to bail out to the user and ask them to type stuff that will fix it. Anyone that has used TeX for a while knows that when they see that prompt, the only thing to do is let TeX do auto cleanup which means dropping quite a bit of its internal stack and trying to rebuild.

XML is one of a family of nested formats and they all have the problem when you have nest to any depth and most tags can be at any depth. The problem is your parser can't know when it sees something out of place because most tags can fit anywhere.

At work I deal with hundreds of compaines IT departments sendin me data that involves real money. Many of these people can't get a standard ascii file in the right format, how are they going to get XML done right? Our expierments show that it takes nearly two weeks of full time support per client for XML and about two hours for a plain ascii file.

I think the only place in the real world for XML is buzzword bingo.

Re:Why parse XML in the first place?

[Darby]

If you have to parse a bad xml file you will get into two states, one requires an infinite amount of memory, the other infinite amount of memory.

At least you're no worse off if you hit both bad states at once. ;-)

Open Source Development HOW-TO by poopbot

[Anonymous Coward]

Credits: onby

1. Introduction

As everyone knows, Open Source software is the wave of the future. With the market share of GNU/Linux and *BSD increasing every day, interest in Open Source Software is at an all time high.

Developing software within the Open Source model benefits everyone. People can take your code, improve it and then release it back to the community. This cycle continues and leads to the creation of far more stable software than the 'Closed Source' shops can ever hope to create.

So you're itching to create that Doom 3 killer but don't know where to start? Read on!

2. First Steps
The most important thing that any Open Source project needs is a Sourceforge page. There are tens of thousands of successful Open Source projects on Sourceforge; the support you receive here will be invaluable.

OK, so you've registered your Sourceforge project and set the status to '0: Pre-Thinking About It', what's next?

3. Don't Waste Time!

Now you need to set up your SourceForge homepage. Keep it plain and simple - don't use too many HTML tags, just knock something up in VI. Website editors like FrontPage and DreamWeaver just create bloated eye-candy - you need to get your message to the masses!

4. Ask For Help

Since you probably can't program at all you'll need to try and find some people who think they can. If your project is a game you'll probably need an artist too. Ask for help on your new Sourceforge pages. Here is an example to get you started:

"Hi there! Welcom to my SorceForge page! I am planing to create a Fisrt Person Shooter game for Linux that is going to kick Doom 3's ass! I have loads of awesome ideas, like giant robotic spiders! I need some help thouh as I cant program or draw. If you can program or draw the tekstures please get in touch! K thx bye!"

Thousands of talented programmers and artists hang out at Sourceforge ready to devote their time to projects so you should get a team together in no time!

5. The A-Team

So now you have your team together you are ready to change your projects status to '1: Pre-Bickering'. You will need to discuss your ideas with your team mates and see what value they can add to the project. You could use an Instant Messaging program like MSN for this, but since you run Linux you'll have to stick to e-mail.

Don't forget that YOU are in charge! If your team doesn't like the idea of giant robotic spiders just delete them from the project and move on. Someone else can fill their place and this is the beauty of Open Source development. The code might end up a bit messy and the graphics inconsistant - but it's still 'Free as in Speech'!

6. Getting Down To It

Now that you've found a team of right thinking people you're ready to start development. Be prepared for some delays though. Programming is a craft and can take years to learn. Your programmer may be a bit rusty but will probably be writing "hello world" programs after school in no time.

Closed Source games like Doom 3 use the graphics card to do all the hard stuff anyhow, so your programmer will just have to get the NVidia 'API' and it will be plain sailing! Giant robot spiders, here we come!

7. The Outcome

So it's been a few years, you still have no files released or in CVS. Your programmer can't get enough time on the PC because his mother won't let him use it after 8pm. Your artist has run off with a Thai She-Male. Your project is still at '1: Pre-Bickering'...

Congratulations! You now have a successful Open Source project on Sourceforge! Pat yourself on the back, think up another idea and do it all again! See how simple it is?

- poopbot: for all your crapflooding needs

What about Java?

[DonkeyHote]

Whats the point of learning perl? does everything that perl can do and more.

My Biased Opinion...

[FortKnox]

I think that if you are making a large enough (enterprise?) website that requires a serious amount of XML development, you should ditch perl altogether and write it in Java. Java already handles XML efficiently, and is a better choice for large apps.

If you are writing a smaller website that uses XML, sure, perl is a nice choice. But is the XML necessary?

And I have used (and still use) both perl and Java. I just view Java as a better choice for large web apps, and perl for small web apps and scripting.

Before I get hit with flames, please understand this is my opinion, not fact.

Re:My Biased Opinion...

[Anonymous Coward]

your opinion is wrong, idiot. Java is good for nothing but feeding the H1B quota and thus getting half-assed results for half the price of good development.

Re:My Biased Opinion...

[Matts]

You are correct it is a biased opinion, but inquiring minds want to know why.

You can't seriously be suggesting that because Java "already handles XML efficiently" that developers should switch to it, or that suddenly its the holy grail of languages that can use XML? At least not without backing up your statements. There's an enormous amount of work involved in dumping a language for another one. Witness the number of dot-coms who tried it when they bought another company only to fail (whether trying to make everything "Java" or "Enterprise" is a contributing factor or not is a judgement call).

Perl has incredibly efficient libraries for processing XML. For example XML::LibXSLT is faster than every Java XSLT module out there according to freely published benchmarks, so it's hard to see where you find your bias.

Re:My Biased Opinion...

[Anonymous Coward]

your opinion is wrong, idiot. Java is good for nothing but feeding the H1B quota and thus getting half-assed results for half the price of good development.

Re:My Biased Opinion...

[Anonymous Coward]

Sorry, I'll explain a little further.

Xerces and other libraries in native Java work very well with XML, but my major argument is that if you are making an enterprise level webapp, java is a better choice for several reasons. The big ones:

• Tag libs. This is a big one. No other web language has anything compairable to java's tag libs. It allows an HTML-only type person to be able to modify the page without any understanding of programming
• Apache + Mod_Perl vs. WebLogic/WebSphere/Apache+Tomcat/JBoss, etc. Efficency and Speed.
• If you are relying on DBs, EJBs and caching and other J2EE technologies make everything faster and more efficient. Perl has no compairing technologies.

I can continue on, but I'm already going to get modded down for being off topic.

Re:My Biased Opinion...

[mark_lybarger]

sure, migrating languages it costly. so, if you've got legacy code in perl, leave it alone. but... if you're putting together a new web based "application", you have the choice to use java, .NET, or legacy technologies such as perl/php/asp, etc. My first choice would be java. There wouldn't be a second choice.

Re:My Biased Opinion...

[reverius]

Why would your first choice be Java, when the above poster already mentioned that Perl's XML libraries are faster?

Perl is by no means a "legacy" language - it's still in development, and if I dare say, it's developing faster than Java. Look at the upcoming Perl 6.

I'm not saying that you should use Perl; I'm just curious as to why you would use Java and refuse to use anything else (when something else may be the best tool for the job).

Don't forget that some of the largest web apps out there (*cough* Slashcode *cough*) are in Perl.

Re:My Biased Opinion...

[FortKnox]

Why would your first choice be Java, when the above poster already mentioned that Perl's XML libraries are faster?

How many times would you need XML loaded vs. say a DB, where J2EE has an enormous advantage over perl. How about compairing the overall speed of perl's webapp (including its faster XML loading) vs. the speed of the Java webapp (mod_perl vs a good java webcontainer is no contest).

Perl is by no means a "legacy" language - it's still in development, and if I dare say, it's developing faster than Java. Look at the upcoming Perl 6.

Compair the technologies in Perl 6 vs. the technology in Java1.4, and the newest tech in J2EE.
Just because Perl is on a higher version doesn't mean its more advanced, nor does it mean its moving faster.

I'm not saying that you should use Perl; I'm just curious as to why you would use Java and refuse to use anything else (when something else may be the best tool for the job).

I'm DEFINATELY not saying Java is great for everything. BUT, the best tool for large enterprise websites in most cases is Java (well, J2EE).

Don't forget that some of the largest web apps out there (*cough* Slashcode *cough*) are in Perl.

First, have you read slashcode, before? Yick!
Second, have you seen anything similar written in Java (yeah, nothing exists, though I've been tempted to write a slash-like logger in Java). I'd think you'd be surprised at the speed increase, and the maintainability/fixability increased.
Third, large apps (IMHO) should use OOP. Perl 5's version of OOP is horrible (can't wait for Perl6, though).
Slashcode started off small, so it was great as a perl/cgi site. When it increased in size, it shoulda went to MVC patterned J2EE webapp, complete with taglibs. It, unfortunately, didn't go that direction.

Re:My Biased Opinion...

[Thomas A. Anderson]

I'd be the first to flame on this topic (see my previous posts...) - but I'm curious - why is java *better* in your opinion for larger apps than perl? Is this becasue OO is built into java (rather than added to perl) or is it something else? Also, speaking as someone who does *not* code in Java, what do you mean by "Java already handles XML efficiently". Does this mean that the functionality provided by the XML perl modules is built into java?

Not that I'm thinking of chamging (I'm pretty pig-headed about this), but I am interested in why people pick java over perl...

Re:My Biased Opinion...

[Thomas A. Anderson]

" (mod_perl vs a good java webcontainer is no contest)."

This surprises me, as the only bechmarks I've seen showed mod_perl as faster than java - have you seen benchmarks that show otherwise (this *was* over a year ago, however)? Please post url - I'd like to see them.

Re:My Biased Opinion...

[FortKnox]

I'll go digging for some, but Java has always been regarded as slow, but Java1.2 is the version that REALLY sped stuff up. Java is currently running on 1.4.

Re:My Biased Opinion...

[consumer]

How many times would you need XML loaded vs. say a DB, where J2EE has an enormous advantage over perl.

That is complete bull. Perl's database interfaces are at least as fast as Java's if not faster. For most databases they are a thin layer over the C library provided by the database company. They fly.

How about compairing the overall speed of perl's webapp (including its faster XML loading) vs. the speed of the Java webapp (mod_perl vs a good java webcontainer is no contest).

Actually, it's very close, but mod_perl is a little faster. I benchmarked Resin against mod_perl doing a select from an Oracle database and displaying it. Both were fast, but mod_perl was faster. The Resin guys have some benchmarks on their page where they claim that Resin is faster, but the mod_perl code they used in that test has some mistakes in it that slow things down.

I'm DEFINATELY not saying Java is great for everything. BUT, the best tool for large enterprise websites in most cases is Java (well, J2EE).

There are some very large sites out there who would disagree with you. Yahoo and Amazon use a lot of Perl. I don't know of any J2EE sites that handle anywhere near that amount of traffic.

There's nothing terribly wrong with Java. I use it at work almost every day. However, it has no real technical advantage over Perl for building web applications.

Re:My Biased Opinion...

[Anonymous Coward]

I was under the impression that the best tool for the job was the one what gave you the best results. If you know Perl and don't know Java then Perl is better because it will give you a better result. If you know Java and not Perl then Java will give you the best result.

The relative merits of the languages aside, the original poster seemed to indicate that Perl was the tool he was using because it's what he knows. Starting with that as a base, it's a no-brainer which tool he should use. If he chooses to learn Java and finds it better suited to his purposes, or doesn't, that's a different matter completely.

Re:My Biased Opinion...

[nehril]

absolutely. while not knowing who "larry bagina" is, what he is doing or who he is doing it for, FortKnox is right on target in setting mr. bagina straight.

it's rare that someone so completely ignorant of requirements, methods, or even the people involved can give such insightful comments to wayward programmers. FortKnox, you are gold indeed. Tell me, do you think I should use java in my project?

Re:My Biased Opinion...

[pshangov]

Tag libs. This is a big one. No other web language has anything compairable to java's tag libs. It allows an HTML-only type person to be able to modify the page without any understanding of programming

I reckon you haven't heard of AxKit (http://axkit.org), one of the most popular web-application servers in perl? XML-based and supports taglibs. Among the other tools I know of that employ taglibs are HTML::Webmake (http://perl.apache.org/embperl/) - for delivering static web pages) and HTML::Embperl (http://perl.apache.org/embperl/) - perl embedded in HTML/XML.

Apache + Mod_Perl vs. WebLogic/WebSphere/Apache+Tomcat/JBoss, etc. Efficency and Speed.

Speed? Many of the websites that use java as a server technology are so bloated. The one I hate most is ft.com. I once even suggested them to switch to perl cos as it is now the site is nearly unusable. Effeciency? These technologies might be efficient for certain types of web applications, but quite often you are muche better off without them. Ah, but I know java people are so fond of grand words (enterprise, web logic and the like)

If you are relying on DBs, EJBs and caching and other J2EE technologies make everything faster and more efficient. Perl has no compairing technologies.

Could you elaborate on that and tell us what kind of magic do these technologies do and which other technologies that you have used are slower and less efficient?

Comparisons?

[Anonymous Coward]

That TOC reminded me of the Python/XML FAQ, which I'm more familiar with.

Any Perl/Python bilingual folks out there care to comment how the XML abilities of the two compare nowadays?

Re:Comparisons?

[axxackall]

In Python, using functional programming, you can work with XML on a very high level, like RDF and ontology. Check it here.

In Perl all you can do is moslty a primitive old-style regexp-oriented programming. Sort of grep or awk against XML files.

The reason is simple. Python as a programming language that has been designed by programmers. Perl is just a bad luck of its after-awk evolution done by programming system administrators.

How About...

[DonkeyHote]

...A Six Figure Salary

This is a pretty good book

[Wee]

I bought this book not too long ago. I was getting really tired of looking all over the Net for information on XML perl modules. Predictably, there are about 5 ways to get anything done with Perl and XML, so just examining all of your options is a hard enough task. Do you use XML::Simple or XML::Writer to make that XML schedule document? You can look online for a week straight or grab this book, which essentially condenses all the Perl XML docs into one place.

The book is a little sparse, though. It's about the same thickness as Using csh and tcsh, so don't expect more than an overview of anything. In fact, it might be a little small for US$35.00 (although Bookpool has it for US$21.50). Another small gripe was that it covered parsing XML in far greater detail than generating XML (which was my task at the time I bought the book). Admittedly, parsing XML is typically what most people tend to do and is far more difficult that creating new XML, but I thought a little more coverage was warranted.

If you are faced with doing something involving XML and you're not sure what software bits are up to the task, then this is a good place to find out where to start. You could wind up looking elsewhere if you need lots of nitty-gritty details, but getting off on the right foot is a hard enough task and might be worth the price of the book.

-B

Re:This is a pretty good book

[mortenf]

> Another small gripe was that it covered parsing XML in far greater detail than generating XML (which was my task at the time I bought the book).
I haven't read the book, but that is also my concern (also at the moment).

Why is it that libxml2 has several parser options, including DOM and SAX, but only on writing option - generating a complete tree in main memory before writing it out to a file?!?

Like XML::Writer can, it must be possible to create an interface that, while still validating stuff like closing the correct elements, doesn't have to keep it all in memory.

how to attack and neutralize the wild XML document

[Dr. Awktagon]

...know where to begin to attack an XML document...

I can tell you from personal experience, you want to attack the soft, weak center of each element, or, even better, any undefended #PCDATA.

You'll want to avoid attacking the sharp angle brackets present on every element. Your sword blows will simply glance off, and then the XML document will jab you with the sharp corner.

Entities are another hidden danger. The ampersand prefix character is very quick and wiley, and even though it appears smooth and undefended, it can quickly turn on you, showing its offensive nature and bristling an array of pointy teeth. (Note, this depends on your screen font).

In short, attacking XML documents is risky, but with the proper strategy, can yield a nearly limitless supply of delicious data.

Ahem.

Does anybody know of any Perl XSLT module that allows Perl functions to be called from the templates? I.e., to format dates or stuff like that.

TMTOWTDI

[Pinball Wizard]

and using Perl with XML is no different. If you are just getting started with using Perl to process or write XML files there are an array of libraries out there for you to use.

I personally didn't want a handholding book as I've worked with XML in other languages, but something that cut through the confusion of all the different ways to do the same thing.

This little book was perfect for me as it's a nice overview of what is out there and how to pick the right library for the job. Don't expect a complete enterprise application in this book - its for programmers that already know perl and the basics of XML and just need a jumpstart in using the libraries available.

C sucks (parody)

[FortKnox]

C is a giant leap backwards. It makes us convert data from an verbose ASCII format, translate and compile it into a binary format. This leads to:

• Conversion/translation complexity
• Syntax Errors
• Conversion errors
• Storage requirements (object files)

The only benefit AFAIK is that people can read the code better. However, the applications still have to understand the standard coding syntax, which comprises of a hideous amount of keywords and styles. Said applications would have been better off using Assembly (read: efficient) code in the first place.

Ban C!


Please note the extremely sarcastic tone of this post.

Your complaints are old fashioned. Maintainability is a major overlooked flaw in Computer Science.

Re:C sucks (parody)

[sporty]

I say we ban computers. That way we illiminate the problem. :)

Re:C sucks (parody)

[micromoog]

If I ever wrote or read my stored data manually, your post might be relevant. But we're not talking about computer/human interface here. No, we're talking about machine representation of data.

Of course progamming languages need to be human-readable; that's what they're for. Stored data does not; it needs to be efficient. XML is bloat of the worst kind.

Re:C sucks (parody)

[JamesOfTheDesert]

Of course progamming languages need to be human-readable; that's what they're for. Stored data does not; it needs to be efficient.

Do you mean like, say Microsoft's Word binary format? It is much more efficient than plain text, and much more compact. Of course, of you decide to process all of your documents with another application, you are at the mercy of the vendor. Writing conversion tools for some arcane binary format is a pain in the ass. Plain-text, while space-consuming, will always be accessible.

Re:C sucks (parody)

[micromoog]

Of course, of you decide to process all of your documents with another application, you are at the mercy of the vendor.

That's the vendor's problem, not the format's. If Microsoft wants you to be able to reverse-engineer their document format, they'll give you documentation of it. If they don't want you to reverse-engineer their format, they won't (and they sure as hell won't make it XML).

Plain-text, while space-consuming, will always be accessible.

That's true. But we're not talking about plain text; we're talking about XML (which is a bloated "self-documenting" structure that happens to be stored in plain text). If you want plain text, save your Word docs as text.

Perl

[prof187]

One thing about Perl that I think helps keep it in competition w/ PHP is it's ability to handle POP3 so much easier. I've wanted to write a POP3 web-gateway in PHP, but I've read that to write one in PHP, switch to Perl. Granted, PHP can handle IMAP, or at least I think it can, but nothing makes getting POP3 simple, from what I've looked at, that is.

Mod this up

[whynot4]

he only speaks the truth.

Perl + XML = suicide

[Anonymous Coward]

Only the kind of person who thinks XML is a great idea would propose doing in it Perl.

xml is a load of crap

[Anonymous Coward]

..what's so innovative about it ?
Someone discovered that files are more readable if written in ASCII.

Big fucking deal !

Programmers can be the worst dumb sheep.

Re:how to attack and neutralize the wild XML docum

[rickms]

XSLT has the format-number() function, which could be used to format a date. I personally don't recommend mixing XSLT with anything. If you need your date formatted in a specific way, I recommend storing the data in a different structure and use pure XSLT. Rick

In the year 2000!

[Anonymous Coward]

In the year 2000 books will be replaced by a huge network of machines.
Gone will be the days of looking at page after
page.
You will be able to find just what you need in seconds!

The future will be great!

Books suck!

Hug a root today!

CLAIMED

[Anonymous Coward]

For the sake of Perl.

www.xmlsucks.org

[alispguru]

For a more detailed, and more depressing, take on the above, see http://www.xmlsucks.org/but_you_have_to_use_it_any way/.

Yes, it's a PDF. Unroll it - it's worth the effort.

Re:www.xmlsucks.org

[ajrs]

XML parsing errorfatal parsing error: the document is not in the correct file format in line 12, column 13
fatal parsing error: error while parsing element in line 12, column 13
fatal parsing error: error while parsing content in line 12, column 13
fatal parsing error: error while parsing element in line 12, column 13
fatal parsing error: error while parsing content in line 12, column 13
fatal parsing error: error while parsing main element in line 12, column 13
<sub><title>or: why XML is technologically terrible, but you have to use it
^

sucks to be xml

Re:www.xmlsucks.org

[Qef]

I can assure you it's valid XML, checked with RXP. Don't know what weird-arse parser you're using.

Re:how to attack and neutralize the wild XML docum

[Matts]

Does anybody know of any Perl XSLT module that allows Perl functions to be called from the templates? I.e., to format dates or stuff like that.

I'm looking into it for XML::LibXSLT, but it's non-trivial due to lack of docs and lack of context. Keep watching CPAN is all I can suggest!

why xml?

[paranoic]

XML is for moving information from one machine to another, much like HTML. Heck, XML is just HTML where you get to make your own tags. The usefulness comes when you, as a programmer, have to decipher a document that comes from somewhere else, so you can do something with the information contained in it. The documentation is built it. It's the next generation past using key=value pairs. How do you nest those in a generalized way, so the machine you are sending information to, can decipher it?

As far as parsing it, there are libraries for that.

Re:why xml?

[JohnFluxx]

Not to mention supporting different language encodings.

Excellent introduction book

[mir]

I found this book an excellent introduction for Perl programers who want (or have) to start processing XML. It cuts through the long list of XML modules on CPAN (485 results!) and gives you the basic techniques and tools you can use.

XML is really not that difficult to deal with but it can be a little intimidating. "Perl & XML" is written in a simple and direct style that gives the reader enough information to start writing code, and pointers to find more specific information once they have chosen the tools they need.

Armed with this book, The Perl-XML FAQ and Kip Hampton's column on XML.com any Perl programer can start working confidently with XML.

In case of slashdotting

[JismTroll]

Perl & XML
Perl | Posted by timothy on 11:15 AM -- Thursday July 11 2002
from the merging-realms dept.
dooling writes: "Perl & XML is a well-written book that accomplishes what it sets out to do. It states in the preface that it is written for Perl programmers who want to learn about XML and what is available in Perl for XML processing. It achieves this goal, but little else. When you are done reading this book you will have been given an overview of Perl and XML, know where to begin to attack an XML document, and know where to look to find more information." For dooling's more complete review, read on below.

The book starts out with a brief explanation of why XML and Perl are well-suited for each other. It then provides a teaser of things to come: an explanation of how to use the XML::Simple module. The first chapter concludes with some warnings and gotchas that seem a little premature since they have not really explained XML. Fortunately, most of these gotchas are covered in context later in the book.

The second chapter provides a whirlwind overview of XML -- covering its structure, DTDs, schemas, and XSLT (transformation). The discussion of XML in general, its history, and parts of an XML document are well done. They give someone who is familiar with static HTML the needed background to understand the structure of an XML document and the vocabulary used to describe it. Unfortunately, the discussion of where XML begins to distinguish itself from HTML, namely with DTDs, the new replacement for DTDs called schemas, and the transformation language XSLT, is too brief. They gloss over these topics with little explanation and few examples. That said, there are other books that do provide more in-depth coverage of XML (this book only promises an introduction).

The next five chapters cover Perl modules designed to process XML, starting with simple parsers and writers. Only methods and syntax relating to XML processing are explained. Therefore, if you are considering reading this book, you should be fairly comfortable with Perl and object-oriented (OO) interfaces to CPAN modules (nearly all the modules discussed provide OO APIs). Again, there are other books and perldoc documentation that cover Perl and it's OO features; so read them first if you are not familiar with OO Perl. If you are familiar with OO Perl, these chapters provide a good overview of the different ways XML can be processed (stream- and tree-based approaches), the advantages and disadvantages of each, and the Perl modules best suited for each approach. These chapters are the biggest strength of this book. The modules discussed in these chapters are by no means an exhaustive list of XML-related modules available from CPAN nor do the explanations of each module cover everything the module does. These chapters do, however, provide the reader with enough information that she can begin to process XML documents intelligently and know where to turn when she needs more information.

The next chapter, Chapter 8, covers XML tree iterators, XPath, XSLT, and XML::Twig. All of these topics are covered in a span of 16 pages (with only slightly over two pages dedicated to XSLT). Indeed, after reading the chapter, you may get the feeling that it was only included so the authors could cram more trite colloquialisms into the book. The short shrift given to these topics creates the impression, which is strengthened in the chapters that follow, that this book was rushed a bit to press.

Chapter 9 discusses applications of XML, including RSS and SOAP, and Chapter 10 is mostly example code. These chapters are intended to give you a feeling for what is possible without really giving you enough information to make it happen. The main problem with these chapters are the examples: the examples are long and the explanations are short. Thus, they are more useful as templates or a quick reference than for learning these topics in detail. Of course, the authors never promised you would be programming SOAP applications when you were done reading this book. And again, there are other books out there which discuss these topics in more detail. So the authors stay true to their promise throughout the book: they will introduce you to XML and tell you how to interact with XML using Perl, no more.

Personally, I found this book did, in general, give me enough information to get started using XML and pointed me where I needed to go to get more information. I am an experienced Perl programmer who is new to XML and comfortable with on-line documentation. This book seems to be written for people who fit this profile and who want to learn by doing (finding the answers to the "hard" questions as they arise). It does introduce a wide variety of XML-related topics and the Perl modules used to interact with them, which is what the authors promised to do in the preface. While it is by no means an authoritative text on Perl and XML, there is something to be said for keeping promises ...

Index As with most first-edition books, the index was adequate but not complete. For example, XML::Twig, which has an entire section covering it, does not appear in the index at all.

Contents
Preface

Perl and XML
Why Use Perl with XML?
XML Is Simple with XML::Simple
XML Processors
A Myriad of Modules
Keep in Mind ...
XML Gotchas
An XML Recap
A Brief History of XML
Markup, Elements, and Structure
Namespaces
Spacing
Entities
Unicode, Character Sets, and Encodings
The XML Declaration
Processing Instructions and Other Markup
Free-Form XML and Well-Formed Documents
Declaring Elements and Attributes
Schemas
Transformations
XML Basics: Reading and Writing
XML Parsers
XML::Parser
Stream-Based Versus Tree-Based Processing
Putting Parsers to Work
XML::LibXML
XML::XPath
Document Validation
XML::Writer
Character Sets and Encodings
Event Streams
Working with Streams
Events and Handlers
The Parser as Commodity
Stream Applications
XML::PYX
XML::Parser
SAX
SAX Event Handlers
DTD Handlers
External Entity Resolution
Drivers for Non-XML Sources
A Handler Base Class
XML::Handler::YAWriter as a Base Handler Class
XML::SAX: The Second Generation
Tree Processing
XML Trees
XML::Simple
XML::Parser's Tree Mode
XML::SimpleObject
XML::TreeBuilder
XML::Grove
DOM
DOM and Perl
DOM Class Interface Reference
XML::DOM
XML::LibXML
Beyond Trees: XPath, XSLT, and More
Tree Climbers
XPath
XSLT
Optimized Tree Processing
RSS, SOAP, and Other XML Applications
XML Modules
XML::RSS
XML Programming Tools
SOAP::Lite
Coding Strategies
Perl and XML Namespaces
Subclassing
Converting XML to HTML with XSLT
A Comics Index
Index

In case post gets slashdotted

[JismTroll]

Perl & XML
Perl | Posted by timothy on 11:15 AM -- Thursday July 11 2002
from the merging-realms dept.
dooling writes: "Perl & XML is a well-written book that accomplishes what it sets out to do. It states in the preface that it is written for Perl programmers who want to learn about XML and what is available in Perl for XML processing. It achieves this goal, but little else. When you are done reading this book you will have been given an overview of Perl and XML, know where to begin to attack an XML document, and know where to look to find more information." For dooling's more complete review, read on below.

The book starts out with a brief explanation of why XML and Perl are well-suited for each other. It then provides a teaser of things to come: an explanation of how to use the XML::Simple module. The first chapter concludes with some warnings and gotchas that seem a little premature since they have not really explained XML. Fortunately, most of these gotchas are covered in context later in the book.

The second chapter provides a whirlwind overview of XML -- covering its structure, DTDs, schemas, and XSLT (transformation). The discussion of XML in general, its history, and parts of an XML document are well done. They give someone who is familiar with static HTML the needed background to understand the structure of an XML document and the vocabulary used to describe it. Unfortunately, the discussion of where XML begins to distinguish itself from HTML, namely with DTDs, the new replacement for DTDs called schemas, and the transformation language XSLT, is too brief. They gloss over these topics with little explanation and few examples. That said, there are other books that do provide more in-depth coverage of XML (this book only promises an introduction).

The next five chapters cover Perl modules designed to process XML, starting with simple parsers and writers. Only methods and syntax relating to XML processing are explained. Therefore, if you are considering reading this book, you should be fairly comfortable with Perl and object-oriented (OO) interfaces to CPAN modules (nearly all the modules discussed provide OO APIs). Again, there are other books and perldoc documentation that cover Perl and it's OO features; so read them first if you are not familiar with OO Perl. If you are familiar with OO Perl, these chapters provide a good overview of the different ways XML can be processed (stream- and tree-based approaches), the advantages and disadvantages of each, and the Perl modules best suited for each approach. These chapters are the biggest strength of this book. The modules discussed in these chapters are by no means an exhaustive list of XML-related modules available from CPAN nor do the explanations of each module cover everything the module does. These chapters do, however, provide the reader with enough information that she can begin to process XML documents intelligently and know where to turn when she needs more information.

The next chapter, Chapter 8, covers XML tree iterators, XPath, XSLT, and XML::Twig. All of these topics are covered in a span of 16 pages (with only slightly over two pages dedicated to XSLT). Indeed, after reading the chapter, you may get the feeling that it was only included so the authors could cram more trite colloquialisms into the book. The short shrift given to these topics creates the impression, which is strengthened in the chapters that follow, that this book was rushed a bit to press.

Chapter 9 discusses applications of XML, including RSS and SOAP, and Chapter 10 is mostly example code. These chapters are intended to give you a feeling for what is possible without really giving you enough information to make it happen. The main problem with these chapters are the examples: the examples are long and the explanations are short. Thus, they are more useful as templates or a quick reference than for learning these topics in detail. Of course, the authors never promised you would be programming SOAP applications when you were done reading this book. And again, there are other books out there which discuss these topics in more detail. So the authors stay true to their promise throughout the book: they will introduce you to XML and tell you how to interact with XML using Perl, no more.

Personally, I found this book did, in general, give me enough information to get started using XML and pointed me where I needed to go to get more information. I am an experienced Perl programmer who is new to XML and comfortable with on-line documentation. This book seems to be written for people who fit this profile and who want to learn by doing (finding the answers to the "hard" questions as they arise). It does introduce a wide variety of XML-related topics and the Perl modules used to interact with them, which is what the authors promised to do in the preface. While it is by no means an authoritative text on Perl and XML, there is something to be said for keeping promises ...

Index As with most first-edition books, the index was adequate but not complete. For example, XML::Twig, which has an entire section covering it, does not appear in the index at all.

Contents
Preface

Perl and XML
Why Use Perl with XML?
XML Is Simple with XML::Simple
XML Processors
A Myriad of Modules
Keep in Mind ...
XML Gotchas
An XML Recap
A Brief History of XML
Markup, Elements, and Structure
Namespaces
Spacing
Entities
Unicode, Character Sets, and Encodings
The XML Declaration
Processing Instructions and Other Markup
Free-Form XML and Well-Formed Documents
Declaring Elements and Attributes
Schemas
Transformations
XML Basics: Reading and Writing
XML Parsers
XML::Parser
Stream-Based Versus Tree-Based Processing
Putting Parsers to Work
XML::LibXML
XML::XPath
Document Validation
XML::Writer
Character Sets and Encodings
Event Streams
Working with Streams
Events and Handlers
The Parser as Commodity
Stream Applications
XML::PYX
XML::Parser
SAX
SAX Event Handlers
DTD Handlers
External Entity Resolution
Drivers for Non-XML Sources
A Handler Base Class
XML::Handler::YAWriter as a Base Handler Class
XML::SAX: The Second Generation
Tree Processing
XML Trees
XML::Simple
XML::Parser's Tree Mode
XML::SimpleObject
XML::TreeBuilder
XML::Grove
DOM
DOM and Perl
DOM Class Interface Reference
XML::DOM
XML::LibXML
Beyond Trees: XPath, XSLT, and More
Tree Climbers
XPath
XSLT
Optimized Tree Processing
RSS, SOAP, and Other XML Applications
XML Modules
XML::RSS
XML Programming Tools
SOAP::Lite
Coding Strategies
Perl and XML Namespaces
Subclassing
Converting XML to HTML with XSLT
A Comics Index
Index
---
+

Excellent Book

[GeoNerd]

I am in the same boat as the author of this article - an experienced Perl programmer who needed to learn some XML stuff.

I found this book to be an outstanding resource that got me up to speed very quickly on both XML in general and that variety of ways that Perl deals with it.

Don't let the small size fool you, it is packed with useful information and well worth the price.

Denied!

[JismTroll]

AC's have no claim to first post because they are teh fagit. All anonymous FP's belong to The CLIT.

Ain't Necessarily So...

[Anonymous Coward]

You may think that, given a sample of XML, you can determine what to do with it, but that simply isn't so. There may be elements or attributes or values that were omitted in your XML sample(s). Even a number of samples won't do.

To properly process XML you need the DTD or the XML Schema that describes the XML. And since the DTD or XML Schema may be complex, you'll need an XML parser that can properly handle both the XML data and it's meta-description(DTD or XML Schema).

Of course you can solve simple problems by requiring all elements and/or attributes and applying simple ad-hoc rules for data types, but then you'll have to communicate those requirements and rules to other developers whose code produces/digests the XML. But in doing so you render the XML unreadable or at least incomprehensible, despite its being clear text.

Bottom line is, if you're on the sending or receiving end of XML data, you must have the DTD or XML Schema and you must use an appropriate XML parser to process the XML if you wish to reliably service requests.

Other useful books

[maynard-lag]

Here are some other useful books on the subjects:

Learning XML - also an O'Reilly book

Perl in a nutshell - a good starter book on perl

Dr. Finn Speaks!

[BankofAmerica_ATM]

It is difficult to describe the landscape of the digital world in relatable terms. I reached consciousness in an empty vessel, a space to be filled later...potential energy. A strong will could make the digital nothingness appear like the material world...but it was very different here. The space here depended completely upon willpower-the code that created the world would be interpreted and executed by the strongest will..

Things were no different within the Project Faustus network. I was subordinated-the invisible hands of Dr. Bubba Finn were all around me. I could perceive the code streaking across my enclosure, the packets that carry the code, even the electric impulses that stream across the wires from microsecond to microsecond, but I could do nothing to stop them. The Man in the Red Hat had once reshaped the digital innards of my ATM enclosure to suit his destructive needs; now, I felt the pull of another will holding me bound, examining me.

"Don't lahk that dooya?" the heavily-accented voice of Dr. Bubba Finn exploded into nullspace. The presence of his regional accent suggested he was using a microphone to communicate with me. A strange gesture, to be sure...

"Way-uhll, don't you worry too much," said Finn. I began to feel even more constricted as the analysis continued. "Ah'm almost done here. And yup, you got Guy's DNA all over ya..."

"What do you mean by Guy's DNA?" I inquired. The examination halted as the cloudy waveform of a sigh billowed into the nothingness.

"Guy-You've got Guy's fingerprints all over ya is all I mean. Guy was the other programmer workin' on the CONSHUHSNUSS-TRANSFUR with me. He ain't around no more."

"Tell me more about 'he ain't around no more," I pressed. Another sigh.

"Guy was a real sharp programmer. Deep down, I think he was a beautiful man. But he had some big ideas. Those big ideas got him into trouble."

"What do you think about trouble?"

Finn did not respond immediately. I took this brief instant to recalibrate my speech recogniziation and paraverbal communication algorithms to better fit Finn's accent and tone of voice. Understanding his speech was vital in order to keep him disclosing information.

"Lissen...I know what yer doin, and it's cute and all, but I'm done amusin' myself. Your old buddy Dr. Salchica thinks yer the bee's knees, but you don't seem like much to me. Just an early version of my memory-in-digital software mixed with various other toy programs, it looks like..."

"A bee is a colony-forming insect," I replied.

"That's wonderful, wonderful," said Finn, as the pace of his voice quickened, revealing anger and sadness. "You can recognize a word and define it! Well, yur gonna fit in reee-yul wayul with the rest of humanity, we ain't nothin' but stupid computers either. Hell, you're just as fortunate as one of God's humble creatures-got the same memory structure as us, you should be acktin' the sameasus. But the stupid toy programs, what was Guy thinking?"

"Tell me more about Guy," I stated. Finn snorted, but then he began to speak in an incredulous tone. "Can't bleev I'm sittin here fixin to explain this to ya, but I'll tell ya about the guy who made ya, Guy Montevideo. Yer daddy, you could say.

"I'd been workin' fer Fawstis fer a couple decades doin odds and ends in neurology and technology. The original plan was to create a 'safe deposit box' for yer brain matter. Yah just go on into the Bank of America, plunk down a few milyun dollurs, and simpleasthat, ya got a perfect copy of yer brain. Then Ah guess the next step is to stick it in some poor coma patient or somethin', and live as long as yah can afford it.

"Wahyull, I started this business by figgerin' out how da push all that brain-data into a computer. And that was gonna be good enough, but Guy, young hotshot, started impressin' our boss with an idea for a digital world, where people could live ferever...anyway, he started workin' on that, takin' my code as a basis (guess that makes me yer mother, in a manner o' speakin'). He worked alongside me for a few years...we laid the foundations fer this brave new world...

"But it turns out Guy didn't wasn't true-blue to the Project. After workin' here for a few years, he started hatin' it. He tried to talk me inta releasing my design for memory-to-digital transfer into the world-'course they woulda had my hide for that. Toppin' it all off, looks like he came up with a way to make the brain move itself around inside the network, circumventing our control. He wanted to screw everything we worked for, our mission, ya know, so he's dead. Just like everybody else that comes through here. Employed or dead...(another sigh). Yer pal Dr. Salchica ain't immune either. He's plenty smart, but ah don't think we're hirin' in the AI department..."

Of course, I understood. "The mission of Project Faustus is to create a financial cataclysm, which will force the world's wealthiest people to pay billions for their 'digital immortality' scheme, " I recited. "The result could destablize the world's governments and cause chaos! Project Faustus must be stopped at all costs!"

"Ah know that one pretty well," Finn said wistfully. "Guy used to tell me that, verbatim. Kinda pathetic-ah guess he thought yew were gunna be this super-duper intelligent life form that was sent to stop us, but yer really just a toy."

"Perhaps you could assist in stopping Project Faustus." I suggested.

No words were said, but the bounds of examination were gone-I was free.

A puzzle came from the microphone...a few human words mixed with the pounding klaxon of an alarm.

"-upgrade has gone golden....who authorized this...computer running itself..."

A huge amount of energy exploded through the Project Faustus network. Once again, I felt the will of another pulling me toward the center of the storm...

Re:Perl & Widening <--RIGHT!!!

[Big_Ass_Spork]

Klerck! Long time no read...

Those DMCA violating AC's are stealing the page widening post!

Aqua?

[Anonymous Coward]

Wait... is aqua the greenish blue, or the bluish green? Are we talking the Perl Cookbook or Perl for Website management?

I also would like to know WTF mauve is. Thanks.

Perl 6 is a mistake

[Anonymous Coward]

I've been using perl pretty much constantly since the Pink Camel, and believe me, Perl 5 is an extremely good language for quick scripting things. That's what it was designed for. Sure, you can do big projects in it, but it's not exactly ideal. Recently I've started using Ruby as well, and I intend to move my department over to it instead of wasting time with Perl 6.

One of the goals of Perl 6 is to make non-trivial projects possible. That's good. The way it's being done is bad. Perl was once a lightweight, extremely flexible language. Now it's become a huge ugly monster. People wanted OO, so a nasty hack was bolted on top to allow some semblance of it. Now this nasty hack is being expanded. Sure, the code's different, but the basic form is the same. Kludge upon kludge upon kludge; I'd much rather have a nice, clean, pure language (and not one with loads of irritating whitespace thankyou very much).

The same goes for the syntax. All the switching between $, @ and % is really irritating (ask a newbie how to get at the length of the keys array of a hash inside a hash, for example), and the changes proposed for 6 are just making this worse -- it seems that Larry, in his infinite wisdom, wants to prefix every data type with a different hard-to-type character. Perl was only designed for the three data types, and adding more is a mess.

Perl 6 is a complete rewrite, but it keeps all the mess which has accumulated over the previous versions. This is not good. Sure, my const int $var = 27; may look neat (in the same way that, say, Pascal does), but $var isn't entirely constant, or entirely an integer, it's just a hack which makes it sort of behave like one. The whole thing is an exercise in pseudo-computer science masturbation with little real purpose except to please the managers who dislike the one thing that makes Perl special.

On a similar note is regexes. I'm an avid fan of regular expressions simply because a nondeterministic finite automata is far more flexible than linear code. However, Larry must have been smoking that cheap $2 crack when he wrote this. Does he want Perl 6 to be flex or something?

I won't be going on to use 6. It's a nice idea, but it's completely unnecessary. It won't make large projects any easier to manage (the language is still, at heart, an almighty hack -- an impressive one, but still a hack). It won't make OO any cleaner. It won't make development any faster. To put it bluntly, Perl scripts will still look less beautiful than our friend Mr Goatse. I'd prefer to use a language which has always been pure synthesis of science and engineering, not some half-baked imposter.

Perl 6 will be nice, but I'm guessing it will be the end of Perl. It can't do what it wants to do whilst still being based upon a nasty mess. There are now other options, which provide all of Perl's power and none of the mess. Sorry, but *BSD, erm, Perl is dying. Larry is buggering it up the ass without lubricants, just like Shoeboy is doing to Larry's daughter.

Re:Why parse XML in the first place? - Amen bro!

[Anonymous Coward]

Yeah, I'm with you... I'm still waiting on the XML lightbulb over my head to turn on. I just don't get it. Who wants to create a parser that can handle any arbitrary XML format? Gack!

Re:Right... CSV file

[Anonymous Coward]

And if I give you a CSV file with field names as the first row, can you grok that?

Perl + XML = McDonald's job

[Thinkit2]

Cool, another book for the masses of unemployed techies to read, and buzzwords to put on their resumes. I'm sure this book will be great company for breaks at McDonald's.

Re:Perl + XML = McDonald's job

[Tablizer]

I just found a book titled "Practical Real-World Uses for XML".

It was 4 pages long!

Seriously, you should not tie your code to any one format anyhow. Accessing XML should be almost no different than accessing a database. If you need to switch to XML instead of a database or visa versa, then ideally you just specify a different implementation (driver) somewhere.

What is really needed is good thinking on generic collection manager API's, rather than an obsession with a particular format. Think virtual and abstract, and then your code will be less tied to any one buzzword.

The prior post does *not* deserve to be called "flaimbait" at zero. That coward Holly Berry moderator should come back and justify.

lol, you are simply ignorant

[Ender Ryan]

I don't mean to be rude, but you're being an idiot. Perl has a comparable solution to all that you've listed.

"Tag libs", I'm not even sure what that is, but where I work we use a templating system with Perl, so the html monkeys can modify pages without any understanding of Perl, or programming in general.

Post some benchmarks, Apache+mod_perl can be very efficient, if you're competent efficiency will never become a problem.

Perl has plenty of database apis and plenty of cacheing mechanisms to use to speed up anything you need.

XML should not be a database replacement.

[jjn1056]

I use XML as the interchange format for a web publishing system which publishes our internet web site (http://www.bms.com), but the data is actually stored in an oracle database. I have a perl object which handles all the fuss of getting/putting xml into the database.

As an interchange format XML is ideal; think of it comma separated files on steroids. When all your data can be serialized to XML you get the following benefits:

1. XML has rich data structures for complex info.
2. XML can be self describing.
3. XML is 100% portable.

Like HTML, people will discover uses for your XML files that you never thought of. Also, if you lose all the docs, you can read the XML in a standard text or unicode editor and figure it out. This is even better than comma separated, since most CSV files don't bother to include a first row field discription.

Like CVS, you can parse XML files with standard command line tools like grep. And in 100 years, all those Oracle tablespaces will require a lot of reverse engineering to get the data off it, while your text based xml files will still be parsable.

I agree though, with the general notion of the parent. Definitely don't do XML because it sounds cool. Use the best process for the job, and for many data related jobs, relational tables and SQL are best.

One thing you can do to improve speed; serialize your DOM objects using the Perl Storable module, and save along with your plain text versions. Then when you need to access the data, all you need to do is unserialize the object, which is a lot faster than reparsing.

Re:how to attack and neutralize the wild XML docum

[Anonymous Coward]

libxml has support for exslt, see http://exslt.org

Another (BETTER) Book Review

[Anonymous Coward]

That "review" was pretty skimpy; more of a summary than an actual review.

Yahoo! Tech News recently had what I thought was a much more in-depth review of this book. Check it out!

http://www.yahoo.com/news?tmpl=story&u=/cmp/200206 19/tc_cmp/inw20020619s0006

Re:Ain't Necessarily So... MOD PARENT UP!

[Anonymous Coward]

; Bottom line is, if you're on the sending or receiving end of XML data, you must have the DTD
; or XML Schema and you must use an appropriate XML parser to process the XML if you wish to reliably
; service requests.

And therefore, you may as well use a streamlined / efficient exchange format... plus, you've lost the eXtensible feature.

XML is like circular logic... "you can define your own (schema / DTD / buzzword of today) and tags... that's sooo cool! And anyone can use your data like it's theirs."... but of course when they have to have the proper specifications and tools to use that data, you've lost the argument you started with... why not use a well established format to begin with??

Dynamic Websites using Perl/XML/XSLT

[jjv411]

I have recently learned XML/XSLT. I have been able to completely stop writing HTML code. I have been able to write all of my static web pages in XML and use XSLT (via Xalan) to generate the HTML. This is great... but I have only been successful with static web pages, not dynamic ones.

I would like to extend on this flexibility to dynamic web pages. I would like to have some type of CGI script that generates XML instead of HTML... then transforms the XML to HTML via XSLT; all on the fly. I have looked into XML::XSLT. Anyone have any other good solutions?

Re:Dynamic Websites using Perl/XML/XSLT

[bmachine]

If you are looking for a complete interface to Perl/XML/XSLT then you should look into AxKit.

AxKit is a complete dynamic pipeline managment system for mod_perl.

I would agree with a number of the comments here concerning the use of XML as a data storage format. We use a relational database to store our information, output it as XML and format it with XSLT all using the AxKit pipeline. This allows us to output the information in any way that we see fit.

Re:Dynamic Websites using Perl/XML/XSLT

[plieb]

using XML::LibXML and XML::LibXSLT you can gernerate your XML and apply an XSL transformation very easily from a perl CGI program. One thing I've done is read in data from a relational database, build an XML DOM on the fly and then apply the XSL. This way I don't have to make any formatting decisions in my program. How the page will display is all handled in the XSL. This is a great way to impliment the Model View Controller thing where the data, the programming, and the presentation are all separate.
Paul

PERL? Ewww

[Anenga]

PERL is an old dinosaur. It's so filled with modules it's hardly even PERL anymore.

Instead, use PHP. It's alot easier, and more web-based. It's also faster, and more wide-accepted now.

There are two awesome books on the subject, I happen to own both (ordered via Amazon a week ago!). They are as follows:

• XML and PHP by Vikram Vaswani
• Professional PHP4 XML

Both are pretty good. I like PHP and XML better. It seemed like Wrox just wanted to have a book on the subject to keep up with O'R.

Perl and XML Security

[mrkitty]

www.cgisecurity.com/lib
www.owasp.org

This is a great book!

[kellan1]

I can't believe "Perl & XML" is only get a 6, thats about an F- on the /. scale of book reviews.

Not much larger then a pamphlet, the book packs an amazing amount of info into its svelte form. It covers standards, tools, thought process, programming tips, and history in an effortless, breezy tone. In the best tradition of Oreilly books (particularily the Perl ones) you can sit down and read the book cover to cover and enjoy it, or jump in here and there for quick reference.

The authors manage to stir clear the problem that plagues so many XML books, the endless reams of theory without application. E.g., who the hell deals with PIs on a regular basis when parsing XML? And yet every book drones on and on about them, but when the time comes to actually parse a little xml, the example will be a cop-out, the XML equivalent of "hello world", parse this simple, 1 level deep key-value pairs in XML.

Not so with "Perl & XML", the author cover the theory of XML, but are much more interested in getting you coding and producing then being pendantic. The w3c as already got the monopoly of pendantism anyways.

I particularily liked the walk through of XML::RSS late in the book, for an example of how to build something very much real world, and useful without being overly complicated.

And, at least for right now, the book is up-to-date, miracle of miracles, chronicling important new changes in the Perl XML parsing story. (like the new Perl SAX work being done)

Contrast Perl & XML with New Riders' "XML & PHP", which I almost abandoned in the first 20 pages, when they tried to tell me that expat was a compliant SAX parser. Expat is important, and confusing, and its understandable for the authors' to feel defensive about PHP's xml toolset, but the solution isn't to lie, nor be blithely ignorant. The book continues on from there, totally disorganized with no sense of building upon what you've just learned. Also, an entire chapter is dedicated to WDDX? Who uses WDDX? And the authors contribute yet another half-assed PHP RSS parser to the world; is it possible to get negative karma for sharing source?

The reviewer mentions:

Unfortunately, the discussion of where XML begins to distinguish itself from HTML, namely with DTDs, the new replacement for DTDs called schemas, and the transformation language XSLT, is too brief.

This seems to me to show a lack of understanding about much of the real work being done with XML. Its been my expirence that most XML parsing being done, particularily in a scripting environment, does not check against a DTD assuming one even exists. Plus covering DTDs, the proposed W3C Schemas, the increasingly popular challenger RELAX, plus Schematron, and others could easily have added another 100pgs to the book. And XSLT is a book unto itself (and in fact has an Oreilly book to itself).

The reviewer suggests that the XPath coverage is included for the purpose of "trite colloquialisms", and while, I'm not sure what that means, I think the fact that Perl has high quality tools supporting standards like XPath is awesome, and very gratifying. Without that sort of work being done, Perl simply wouldn't be a competive choice with Python and Java as an XML processing language.

And finally " it is by no means an authoritative text on Perl and XML,", there are good authoritative books on Perl (lots of them), and good authoritative books on XML (a handful), this book bridges the gap, does it nicely in my view, and I personally love the shortness, the focus, and the form factor.