An efficient mechanism for Matching multiple patterns on XML Streams

AN EFFICIENT MECHANISM FOR MATCHING MULTIPLEPATTERNS WITH STREAMED XML DATA<strong>An</strong>dreas Hinnerichs, Edzard HöfigFraunhofer FOKUSKaiserin-Augusta-Allee 31, D-10625 Berlin, Germanyemail: {hinnerichs|hoefig}@fokus.fraunhofer.deABSTRACTFiltering XML data streams using <strong>efficient</strong> patternmatching algorithms is a fundamental ability <strong>for</strong> manydata-centric applications and main purpose of theTemplate <strong>Matching</strong> sPecification Language (TMPL).In this paper extensions to the language are discussedthat help to <strong>for</strong>mulate more powerful query <strong>patterns</strong>:The declarative type system, improved predicates,template references and sequence matching operators.<strong>An</strong> optimised matching runtime based on lazy constructedautomata is introduced together with an explanationof the underlying <strong>for</strong>malism. <strong>An</strong> Example,case studies and per<strong>for</strong>mance measurements illustratethe usage and usability of TMPL.KEY WORDSProgramming Tools and Languages, XML, StreamProcessing, Template <strong>Matching</strong>1 OverviewThe self descriptive eXtensible Markup Language(XML) is at the heart of many data-centric applicationsin use today. For most of these applications atimely analysis of their large quantities of data is onlypossible using a stream processing approach. As oftenonly a fraction of the data to be processed is of interest,there is a need <strong>for</strong> the employment of <strong>efficient</strong>filter <strong>mechanism</strong>s. For example, we processed a largelog file to extract statistical data used in per<strong>for</strong>manceassessment of a business system: Out of the 1.2 Gigabytesof log data only about1130was of interest <strong>for</strong>calculation of the per<strong>for</strong>mance values. The best practice<strong>for</strong> sorting out the important pieces of data is theutilisation of an <strong>efficient</strong> one-pass parsing algorithm.Our approach is based on the idea that datastreams are always exhibiting a recurrent structurein a particular size and of characteristic <strong>patterns</strong>.The gathering of values is done by creating such <strong>patterns</strong>— so-called templates — in a XML-like syntaxand marking parts of the pattern <strong>for</strong> later processingin a general-purpose programming language 1 .<strong>An</strong> analysing application would then use our templatematching engine <strong>for</strong> comparing these templates against1 Currently Javaa possibly infinite XML data stream and would be notifiedwhen a match is detected with the name andidentified values of the matched template.In this paper we describe the concepts that arethe basis <strong>for</strong> an extension of TMPL and its runtime(see [1] <strong>for</strong> a description of the original concepts)enabling an <strong>efficient</strong> parallel matching of templates,matching of pattern sequences by means oftemplate references, and better integration with theanalysing applications by using a declarative type system.The remaining text is structured as follows: Firstan overview about the related work is given in section2. In section 3 extensions to TMPL are describedand a new approach to the runtime architecture isintroduced together with a discussion about changesin matching semantics. A new matching <strong>mechanism</strong>is introduced and implications to runtime behaviourare detailed in section 4 along with an example. Thenext section 5 discusses applications by delivering per<strong>for</strong>mancemeasurements and comparing our approachwith alternative technology. Section 6 concludes bypresenting a summary, open topics and future steps inthe development of TMPL.2 Related WorkDiverse <strong>mechanism</strong>s <strong>for</strong> <strong>efficient</strong> pattern matching onXML data streams have been researched. Usually aconventional technology used with document basedXML data (e.g. XPath, XQuery or XSLT) is adoptedto the requirements of stream processing.In [2] Olteanu, Furche, and Bry introduce theSPEX engine which allows to evaluate a subset ofXPath on streamed data by translating XPath expressions,containing only <strong>for</strong>ward axis, to a network oftransducers. Becker proposes STX (see [3]), a XSLTlike language that allows <strong>for</strong> the creation of templatesthat can be matched against an XML data stream.STX has a Java implementation called joost that wecompare our approach against in section 5. In [4] Fegarasexplains XStreamQuery, a transducer based implementationof an analysis engine which is using SAX.XQuery expressions may be translated to XStream-Query expressions and could then be executed by theXStreamQuery engine.

This paper discusses XML stream data processingfrom the perspective of TMPL, a language thatwas specifically designed <strong>for</strong> stream analysis and notadopted from a document based approach. TMPL wasintroduced in [1], further in<strong>for</strong>mation on related workin this field may be found in this paper, as well.3 Language ExtensionsTMPL is a context-sensitive language describing <strong>patterns</strong>that are to be matched against a data stream.Syntactical structures of TMPL are specified in asyntax quite similar to XML itself and may consistof elements, attributes and data specifications in the<strong>for</strong>m of so-called predicates. Predicates are denotedusing square brackets and may restrict content (e.g.a statement like a=[>10] would match only if thecorresponding attribute posses a value greater thanten) or assign a value to a variable (e.g. [=:b]would assign the content of the element to avariable of name b). There are additional symbols <strong>for</strong>marking a single unknown element or an element at anunknown depth 2 in the XML data stream. A TMPLfile defines a single module that contains severaltemplates and it is possible to define constants at thebeginning of a template or module scope. Variablesor constants may also be referenced in predicates (e.g.[$c] matches if an unknown element is beencountered that contained the value stored in thevariable referenced by the name of c). Based on theexperience we gained while applying the languageduring the last year, we extended the functionalitywith features we were missing, which either improveexpressiveness by enabling the matching of previouslynot identifiable <strong>patterns</strong> (e.g. sequence matching) orincrease usability of the language by reducing possibletypos or failures on the user’s side (e.g. declarativetype system).To accommodate certain new runtime features itbecame necessary to change the TMPL toolchain. Figure1 depicts the current toolchain in white colour; thegrey part shows the old approach that was directlygenerating Java code from the TMPL abstract syntaxtree (AST) as constructed by the parser. Thishas been dropped in favour of a new intermediary <strong>for</strong>matthat codifies the automata <strong>for</strong> the runtime engineusing an extended finite state machine (EFSM) <strong>for</strong>malismwhich will be described in section 4.1.The basic idea was to be able to use this <strong>for</strong>matin several ways. <strong>An</strong> automaton may be savedin, or loaded from a file using the standard Graph eXchangeLanguage (GXL) <strong>for</strong>mat (<strong>for</strong> more in<strong>for</strong>mationplease refer to the website [5]). Templates in the intermediary<strong>for</strong>mat are used directly with the TMPL2 Stream depth is defined as the nesting level of elementsgxltmplParserAutomataGenerationInterpreterJavaGenerationjavaCompiledRuntimeFigure 1. TMPL tool chainInterpreter, that is the matching runtime engine, tosearch <strong>for</strong> <strong>patterns</strong> in the data stream. Some other optionsnot shown here would be to generate specialisedmatching code directly from the intermediary <strong>for</strong>mat<strong>for</strong> a certain programming language or to use standardvisualisation software to generate pictures of the statemachines.3.1 Syntactical ChangesThe syntax of TMPL has been slightly changedto be better understandable. Explicit comparisonand assignment operators have been introduced (e.g.[=$foo] and [=:bar]) which may be omitted whentheir meaning within a predicate is non-ambiguous.There is a shorthand syntax <strong>for</strong> other syntactical constructsas well, please refer to the website [6] <strong>for</strong> documentationabout these.A major change is the introduction of the rangeelement that offers a clearer definition than the<strong>for</strong>mer placeholder expression. One can use it to matcha sequence of nested elements. As an example considerthe following TMPL code:In this case the range element stands <strong>for</strong> a sequencethat has to begin with a child element of and that must end with an element containing attributeatt and child element b. The range element ismatched successfully when the starting element of thesequence closes.

3.2 Declarative Type SystemThe introduction of a declarative type system ismotivated by several reasons. For starters, one wantsto precisely specify types to be matched as attributevalues or element content, e.g. an attribute containinga numeric value should only be captured from theinput stream if such a type has been specified andshall be further processed using a suitable type inthe language that the template match is reportedto, waiving the need to cast the data to a new type.We decided to use a static type system due to thenature of TMPL templates, which are also staticand described as a closed structure. Users are <strong>for</strong>cedto explicitly detail all the data that may match <strong>for</strong>a certain template, making it easier to design andmaintain all but the simplest <strong>patterns</strong>. A user canconclude the structure of matched data simply byreferring to the structure of the data definitions,without combing through the complete templatedefinitions.All constants, variables or template referencesneed to declare a name and a type be<strong>for</strong>e beingused; this is done at the beginning of any template,right after opening the scope and be<strong>for</strong>e the definitionof any structures. Variables may and constantsneed to have a default value which is assignedas part of the declaration. For example theline const integer count = 10; declares a constantwith the name count and the type integer and assignsa default value of 10. The TMPL type systemprovides five basic types:string Is a character string. <strong>An</strong>y such value mustbe given as a sequence of characters enclosed betweendouble quotes. This corresponds to the native(and only) type used in XML.integer Declares an integer number. This is representedas a simple number. Integers are of arbitrarylength but may be limited by the implementationof the engine.float Declares a floating point type. Floating pointnumbers bear an arbitrary precision which maybe limited by the implementation language of theengine. A float value is given as two numbers witha . between them.bool Holds a boolean value and may be either trueor false.template Declares a reference to another template.3.3 Template ReferencesDuring application of the language we often cameacross situations where a similar pattern was appearingin a lot of templates (header data <strong>for</strong> example). Toease handling of these kinds of templates, referenceswere introduced. A template can be made abstractwith the result that matches of this template are notreported to the application. Templates that are declaredabstract may be referenced by other templatesusing the template type, enabling the matching of sequencesof similar <strong>patterns</strong> and also caring <strong>for</strong> definitionof optional parts. Technically, when referencingtemplates one is allowed to use a quantifier symbol.If no quantifier is present the template has to occurexactly once at the given position (<strong>for</strong> an example seesection 4). There are five valid quantifiers allowed withthe following meaning (t1 and t2 stand <strong>for</strong> templatereferences):t1? The reference t1 is optional. It may appear or itmay not.t1+ The reference t1 may match one or more times.t1* The reference t1 may match several times or notat all.t1 | t2 | ... Either one of given the references (t1,t2 or . . . ) matches. If several references matchthe leftmost template is chosen. The or quantifierallows <strong>for</strong> an arbitrary number of operands.t1 & t2 & ... All given references (t1, t2 and . . . )have to match at the same time. The and quantifierallows <strong>for</strong> an arbitrary number of operands.Depending on the quantifiers template types have tobe declared either as a scalar type or a sequence. Thesyntax uses square brackets to denote a sequence type.For example template foo[] t1; declares a templatereference with the name t1 which will be used to referencea sequence of abstract foo templates.3.4 Improved PredicatesIn the <strong>for</strong>mer version of the language only trivial predicateslike comparison and assignment with the currentlymatched token and one additional operator werepossible and even these only on values of attributes orcontent in elements. It was soon obvious that an improvementof predicates with more sophisticated operationslike regular expressions, range restrictions or theability to test a variable would be of great value to theapplicability of the language. Predicates have there<strong>for</strong>ebeen significantly extended. They are allowed tonot only specify attribute and content values, but alsoto define the name of elements. When a predicate isenclosed between the symbols [: and :] it is evaluatedas a regular expression 3 .3 The regular expression dialect in use is currentlythat of Java (<strong>for</strong> more in<strong>for</strong>mation please refer to thejava.util.regex.Pattern class)

Predicates may also evaluate a boolean expressiongiven by combinations of relational operators (=,!=, , =), the assignment operator (=:), logicaloperators (|, &, !), brackets ((, )), variable references(using $) or the current value from the XMLdata stream (if an operand is left empty). Variable referencesmay be complex as they also need to care <strong>for</strong>template references. For example $foo.bar[3].dingidentifies the value of the field ding of the 3. elementin the sequence bar, where bar is a field of the scalarfoo. The definition of TMPL has a set of rules thatgovern the exact evaluation of predicates. We will notgo into more detail in this article. Please refer to thedocumentation found at the website [6].3.5 Allowing Mixed ContentThe language allows <strong>for</strong> matching of mixed content;values are allowed to appear unrestricted among theXML tags and not only as a single child of an element.Opposite to other processors, the TMPL engine treatsleading and trailing white space as empty content andstrips it from the data.4 Changes in the Evaluation RuntimeImplementation of the stream analysis runtime haschanged considerably, as shown in figure 1. The evaluationengine is interpreting EFSM template matchingautomata using a proprietary binary <strong>for</strong>mat or GXLenabling a more flexible handling of templates, e.g. itis now possible to add or remove templates during runtimeand to combine automata. Per<strong>for</strong>mance of thisapproach using only a single template is inferior tothe <strong>for</strong>mer compiled version, but superior when severaltemplates are matched in parallel.4.1 Automata GenerationThe <strong>for</strong>malism <strong>for</strong> generated automata had to supportcontext (which may be values from the data stream,TMPL declared variables and constants, or internalvariables used by the evaluation engine) and transitionsthat may depend on any of them. These premiseslead to the adoption of an EFSM <strong>for</strong>malism. Morespecifically we choose to extend the one proposed byHenniger and Neumann (see [7]) because of the abovementioned features, the additional support <strong>for</strong> internalɛ transitions and the ability <strong>for</strong> transitions to changethe complete context of an automaton.<strong>An</strong> EFSM is defined as a tuple(S, C, I, O, T, s 0 , c 0 ), where S is a finite set ofstates, C the context 4 , I a non-empty finite setof input events including ɛ, and O a non-emptyfinite set of output events. T denotes the transition4 All possible values of a finite set of variablesrelation from current state, context and input eventto the next state, modified context and output event(T ⊆ S × C × I × O × S × C). The two last elementss 0 and c 0 describe the initial state and context values.Every TMPL component (element, content, attribute,template reference, . . . ) is translated to oneor more states that are combined to a graph using<strong>for</strong>ward and reverse transitions. A <strong>for</strong>ward transitionis understood as to be leading towards the endstate, whereas a reverse transition is used when a pathcannot completed, e.g. when a parent XML elementcloses. As an example consider the following template<strong>for</strong> searching a (hypothetical) music database:template fooMusicList {}const integer c = 10;float ranking;template tSingle[] single;template tAlbum[] album;$c]>[=:ranking]single*album*The template fooMusicList would be translated toan EFSM similar 5 to the one shown in figure 2. Astraight <strong>for</strong>ward path through the generated automatonis marked with bold transition lines. Several detailsmight be associated with a transition: contextconditions which are enclosed in square brackets, actions<strong>for</strong> changing the context in curly brackets, an inputevent from the XML Stream (e.g. START, END,ATTRIBUTE, . . . ) and an output event or none inthe case of an ɛ transition.The first two states are used to initialise constantsand output variables; the matching processstarts in the START and stops in the END statewhere a matching pattern has been identified whichwill be reported back to the analysing application.For every element the generator constructstwo states that match corresponding XML startand end elements (e.g. MATCH AUTHOR andMATCH AUTHOR END); <strong>for</strong> attributes the automatonhas a state that first registers each attribute’sname and then uses a single state to match all of them,this is similar <strong>for</strong> content. Template references aretranslated as single states.5 Some details emitted <strong>for</strong> brevity of examples.

SET_ATTRIBUTESTART[author]{SET(name,Foo Fighters)SET(titles,>c)}MATCH_2_ATTRIBUTESSET_CONTENTLIST_END[false]ATTRIBUTE{CHECK()}LIST_END[true]INIT_CONSTANTINIT_VARIABLESTARTMATCH_AUTHORMATCH_REG_ELEMENTSTART[fan*][=TOP+1]{SET(:=ranking)}START ENDMATCH_CONTENTCONTENT[true]MATCH_REG_ENDEND[=TOP]MATCH_MUSICMATCH_SINGLE_STAR{SET_CONST(c,10)}{SET_VAR(single,LIST)SET_VAR(album,LIST)SET_VAR(ranking,FLOAT)}END[=TOP]END[=TOP]START[music][=TOP+1]MATCHED[tAlbum][=TOP]END[=TOP]MATCHED[tSingle][=TOP]4.2.1 Parallel Execution of TemplatesThe basic idea behind this is to combine several templates,this is a standard procedure in graph theory:by using the cross product a combined automaton maybe calculated (please refer to [8]). It is still inevitableto check conditions <strong>for</strong> all transitions; the per<strong>for</strong>mancegain is solely the difference between the time one needsto execute a single state transition or several ones.The downside to this approach is in the exponentialincrease in states and transitions. For exampletake two EFSM S 1 and S 2 with p i number of states andq i number of transitions: a resulting EFSM <strong>for</strong> S 1 ×S 2would have p 1·p 2 states and at least p 1·q 2 +q 1·p 2 transitions.A combination of ten EFSM with ten stateseach (e.g. templates having three elements and twocontent predicates) would end up with 10 billion (10 10 )states and far more transitions. As the authors of [9]point out, a possible solution to this dilemma is to uselazy construction principles <strong>for</strong> the automata.4.2.2 Lazy Automata ConstructionEven if the hypothetical number of states of a combinedEFSM seems to grow to exorbitant numbers onlya very small portion of these states would ever be used.If an automaton is build in a lazy fashion by constructingnew states at runtime only when they are needed,this number may be decrease dramatically. For examplewe combined twelve templates with altogether 350states using a lazy construction principle and endedup with an EFSM of only 169 states <strong>for</strong> a specific datastream after further optimisations that reduced redundantor empty states and transitions.END[=TOP]MATCH_ALBUM_STAREND[=TOP]MATCH_AUTHOR_ENDMATCHED[tAlbum][=TOP]END[=TOP]ENDTEMPLATE_MATCH()Figure 2. Automaton <strong>for</strong> template fooMusicList4.2 OptimisationWith the interpreting approach in place, several newoptimisations have become possible. One of the mostimportant ones was the combination of several automatain one larger EFSM.4.2.3 State and Transition ReductionThere are several ways to further reduce the numberof states and transitions when combining automata:Merging of ɛ transitions <strong>An</strong>y number of statesthat are connected solely by ɛ transitions aremerged to two states with a single connecting ɛtransition.Removal of initialisation states Initialisationfunctionality does not need to be considered bythe combination algorithm but may be executedseparately.Removal of default self-transitions When no inputevent selects a transition an EFSM needs tostay in its current state. This can be made defaultbehaviour and then does not need to be made explicitby a self-transition.Grouping transitions By grouping transitions witha common condition (e.g. same nesting level or

input event) only the group needs to be testedand not all transitions individually.5 Application ResultsTMPL is in use <strong>for</strong> a number of projects and the extendedversion of TMPL as presented in this paperhas only been functionally tested in some case studies.Results obtained in these case studies were producedon a standard desktop PC and are promising.5.1 Open Directory ProjectThe Open Directory Project 6 calls itself the “largest,most comprehensive human-edited directory of theWeb” and makes its content freely available amongother things in the <strong>for</strong>m of downloadable XML archivefiles. We used seven files ranging from 24 kbyte tonearly 2 gigabyte size and extracted all directory topics,their assigned links and associated titles usingboth TMPL templates executing with the optimisedinterpreter and STX stylesheets using the joost runtime7 . TMPL exports the filtered values directly toan analysing Java application, whereas STX creates atrans<strong>for</strong>med XML file with the same in<strong>for</strong>mation. Figure3 shows execution results obtained using built-intime measurement functions of STX, respective Java.5.2 Further Case StudiesTo test optimisations <strong>for</strong> the TMPL runtime we wereusing a 23 megabyte logging file containing morethan 800 data entries of protocol messages <strong>for</strong> per<strong>for</strong>mancemeasurement purposes and filtered in<strong>for</strong>mationlike timestamps, message types, destination address,. . . using 1 up to 12 different templates. Figure4 shows a comparison of the speed <strong>for</strong> analysis of thestream data depending on the number of used templates<strong>for</strong> an unoptimised interpreter implementation,a combined state version with lazy construction and aversion with all optimisations.Time in seconds121086420InterpreterCombined InterpreterOptimised Interpreter1 2 3 4 5 6 7 8 9 10 11 12Number of templatesFigure 4. Per<strong>for</strong>mance comparison of optimisations600500Time in seconds4003002001000TMPLSTX0 500 1000 1500 2000Size in megabyteFigure 3. Open Directory Project archive searchIt is to be observed that the STX engine is faster<strong>for</strong> smaller data amounts but after “warm-up” of thelazy construction <strong>mechanism</strong> the optimised TMPL interpreteris up to 1 3faster than STX. It is unlikelythat still larger amounts of data would change this.<strong>An</strong>other argument in favour of TMPL is that to writeboth versions of template definitions in TMPL 15 linesand in STX more than 30 lines are needed. BecauseTMPL syntax is not valid XML we argue that it ismore intuitive and easier to read and understand asthe XSLT based syntax that STX uses.6 http://dmoz.org/7 http://joost.source<strong>for</strong>ge.net/6 ConclusionThe extensions to TMPL introduced in this paper havebeen found useful in making the language more powerfulwhen <strong>for</strong>mulating <strong>patterns</strong> while preserving theintuitive and clear syntax. The utilisation of lazy constructedautomata <strong>for</strong> matching <strong>multiple</strong> templates inparallel is feasible and offers a good runtime per<strong>for</strong>mance.Experience during the implementation showsa linear increase in processing time depending on increaseof the analysed data size. The optimisation approacheswork best <strong>for</strong> templates and data streamsthat bear a lot of similarity.6.1 Open TopicsNested <strong>patterns</strong> The self similarity problem (asmentioned in [1] page 116) is not solved. A templatethat is already matching will not start tomatch again; this problem also exists with abstracttemplates. There<strong>for</strong>e abstract templatescan only be used to alleviate the burden of writingthe same template over and over again, but notto specify relations on a more abstract level thanthe natural granularity of the underlying stream.

This is a restriction of the TMPL runtime and resultsin the impossibility to identify nested, selfsimilar<strong>patterns</strong> in a XML stream. Of course, ifthe structure of a certain pattern to be matched isknown in sufficient detail in advance, it is alwayspossible to create a template that will match thisexact structure even if parts of it are self-similar.We don’t regard this as a too serious issue as byfar most of the XML data in use is not-self similar(VALUE according to the authors of [10, ch.3.6]) and of the remaining share, only a very smallfraction (VALUE) is deeply nested and there<strong>for</strong>erequiring the creation of complex static templates.Namespaces The namespace <strong>mechanism</strong> of XML isstill not supported in TMPL. The only solutionto this is to explicitly prefix every name to yieldits qualified representation (e.g. using ns:foo).6.2 OutlookUsing <strong>multiple</strong> threads When analysing XMLdata using machines with many CPUs or processorcores, implementing the matching runtimein a multithreaded fashion might provide asignificant better runtime per<strong>for</strong>mance. Thisapproach would probably work quite well as alltemplates are able to run in parallel and shareonly the input event from the data stream.Further improvement of predicates Usage ofpredicates could still be improved, <strong>for</strong> example byadding numerical operators (+,-,*,/), or functions(e.g. to calculate the length of lists).[3] O. Becker, Serielle Trans<strong>for</strong>mation von XML -Probleme, Methoden, Lösungen. PhD thesis,Humbolt-University, Berlin, 2004.[4] L. Fegaras, The Joy of SAX. Proc. 1th InternationalWorkshop on XQuery Implementation,Experience and Perspectives (ACM SIG-MOD) pp. 61-66, 2004.[5] R. Holt, A. Schürr, S. E. Sim, and A. Winter,Graph eXchange Language www.gupro.de/GXL/[6] E. Höfig, A. Hinnerichs: TemplateSpecification Language Websitehttp://source<strong>for</strong>ge.net/projects/tmpl[7] O. Henniger, and P. Neumann, Test case generationbased on <strong>for</strong>mal specifications in Estelle.In J.-D. Decotignie, ed., Proc. of the1st IEEE International Workshop on FactoryCommunication Systems, 1995.[8] F. Harary, Graph theory(Reading, Mass. :Addison-Wesley Pub. Co., 1969).[9] T.J. Green, G. Miklau, M. Okizuka, andD. Suciu, Processing xml streams with deterministicautomata. Proc. 9th InternationalConference on Database Theory pp. 173-189,2003.[10] L. Mignet, D. Barbosa, and P. Veltri, TheXML Web: a First Study. Proc. 12th internationalconference on World Wide Web pp.500-510, 2003.Template parametrisation Templates could beparametrised and supplied with certain values atruntime, enabling matching of a greater varietyof <strong>patterns</strong> using template references.Improvement of template references One couldallow complex sequence definitions of templates,<strong>for</strong> example by adding predicates to template referencesor by using qualified references in combinationwith logical operators.References[1] E. Höfig: Template <strong>Matching</strong> on XMLStreams. Proc. 24th IASTED Software Engineeringpp. 113-118, 2006.[2] D. Olteanu, T. Furche, and F. Bry: <strong>An</strong> EfficientSingle-Pass Query Evaluator <strong>for</strong> XMLData Streams. Proc. 19th <strong>An</strong>nual ACM Symposiumon Applied Computing (SAC) ,2004.