1. Where the Document Object Model (DOM) is used?
Document Object Model (DOM) is used to query, traverse and manipulate documents like XML or HTML documents. DOM is best suited where the document must be accessed repeatedly or out of sequence order. DOM allows accessing the contents of a web page. It also allows dealing with events that allows capturing and responding to user's actions. There are different levels of DOM standards depending on the compatibility of the browsers.
DOM is a platform independent, World Wide Web Consortium (W3C) standard form of representation of structured documents as an object-oriented model. It is an application programming interface so as to access HTML and XML documents.
3. Explain the difference between DOM and SAX?
SAX parser works incrementally and generates events that are passed to the application. DOM parser reads the whole XML document and returns a DOM tree representation of xml document
In DOM the xml file is arranged as a tree and backward and forward search is possible In SAX traversing in any direction is not possible as Top to bottom approach is used.
SAX is essentially an API for reading XML, and not writing it. DOM allows you to read and write.
DOM is Document Object Model. It is used to read data from a XML document. It is more commonly used in applications where data in the document needs to be repeated accessed. DOM supports navigation in any direction. XML DOM is typically used for XML documents. The DOM defines the objects and properties of all document elements, and the methods (interface) to access them.
The HTML DOM API specializes and adds the functionality to relate to HTML documents and elements. It addresses the issues of backwards compatibility with the Level 0 of DOM and provides mechanisms for common and frequent operations on HTML documents.
6. Define XMLHttpRequest Object?
The XMLHttpRequest object is used to connect to the server through http. Scripts use it to do so programmatically.
The EventTarget interface needs to be implemented if an object implements the XMLHttpRequest interface. Also, an XMLHttpRequest() constructor needs to be provided by objects that implement the Window interface.
CVS is intended to handle source control for files in three major situations: 1. Multiple developers working on the same files.The major advantage of using CVS over the simpler tools like RCS or SCCS is that it allows multiple developers to work on the same sources at the same time.The shared Repository provides a rendezvous for committed sources that allows developers a fair amount of flexibility in how often to publish (via the "commit" command) changes or include work committed by others (via the "update" command). 2. Tracking a stream of releases from a source vendor.If you are making changes to sources distributed by someone else, the CVS feature, called the Vendor Branch, allows you to combine local modifications with repeated vendor releases.I have found this most useful when dealing with sources from three major classes of source vendor: a. Large companies who send you tapes full of the latest release (e.g. Unix OS vendors, database companies). b. Public Domain software which *always* requires work. c. Pseudo-Public sources which may require work. (e.g. GNU programs, X, CVS itself, etc.) 3. Branching development.Aside from the "Vendor Branch", there are three kinds of "branches in development" that CVS can support: a. Your working directory can be treated as a private branch. b. A Development branch can be shared by one or more developers. c. At release time, a branch is usually created for bug fixes. (See 1D.9 and Section 4C for more info on branches.) CVS's branch support is a bit primitive, but it was designed to allow you to create branches, work on them for while and merge them back into the main line of development.You should also be able to merge work performed on the main branch into the branch you are working on. Arbitrary sharing and merging between branches is not currently supported.
CVS saves its version-control information in RCS files stored in a directory hierarchy, called the Repository, which is separate from the user's working directory.Files in the Repository are stored in a format dictated by the RCS commands CVS uses to do much of its real work. RCS files are standard byte-stream files with an internal format described by keywords stored in the files themselves.To begin work, you execute a "checkout" command, handing it a module name or directory path (relative to the $CVSROOT variable)you want to work on. CVS copies the latest revision of each file in the specified module or directory out of the Repository and into a directory tree created in your current directory. You may specify a particular branch to work on by symbolic name if you don't want to work on the default (main or trunk) branch.You may then modify files in the new directory tree, build them into output files and test the results.When you want to make your changes available to other developers, you "commit" them back into the Repository.Other developers can check out the same files at the same time.To merge the committed work of others into your working files you use the "update" command. When your merged files build and test correctly, you may commit the merged result. This method is referred to as "copy-modify-merge", which does not require locks on the source files.At any time, usually at some milestone, you can "tag" the committed files, producing a symbolic name that can be handed to a future "checkout" command. A special form of "tag" produces a branch in development, as usually happens at "release" time. When you no longer plan to modify or refer to your local copy of the files, they can be removed.
9. What is CVS *not* useful for?
CVS is not a build system.Though the structure of your Repository and modules file interact with your build system (e.g. a tree of Makefiles),they are essentially independent.CVS does not dictate how you build anything. It merely stores files for retrieval in a tree structure you devise.CVS does not dictate how to use disk space in the checked out working directories. If you require your Makefiles or build procedures to know the relative positions of everything else,you wind up requiring the entire Repository to be checked out. That's simply bad planning.If you modularize your work, and construct a build system that will share files (via links, mounts, VPATH in Makefiles,etc.), you can arrange your disk usage however you like.But you have to remember that *any* such system is a lot of work to construct and maintain. CVS does not address the issues involved. You must use your brain and a ollection of other tools to provide a build scheme to match your plans.Of course, you should use CVS to maintain the tools created to support such a build system (scripts, Makefiles, etc).CVS is not a substitute for management.You and your project leaders are expected to plan what you are doing. Everyone involved must be aware of schedules, merge points, branch names, release dates and the range of procedures needed to build products. (If you produce it and someone else uses it, it is a product.) CVS can't cover for a failure to manage your project.CVS is an instrument for making sources dance to your tune.But you are the piper and the composer. No instrument plays itself or writes its own music.CVS is not a substitute for developer communication.When faced with conflicts within a single file, most developers manage to resolve them without too much effort.But a more general definition of "conflict" includes problems too difficult to solve without communication between developers.CVS cannot determine when simultaneous changes within a single file, or across a whole collection of files, will logically conflict with one another.Its concept of a "conflict" is purely textual, arising when two changes to the same base file are near enough to spook the merge command into dropping conflict markers into the merged file.CVS is not capable of figuring out distributed conflicts in program logic.For example, if you change the arguments to function X defined in file A and, at the same time, edit file B, adding new calls to function X using the old arguments.You are outside the realm of CVS's competence.Acquire the habit of reading specs and talking to your peers.CVS is not a configuration management system.CVS is a source control system. The phrase "configuration management" is a marketing term, not an industry-recognized set of functions.A true "configuration management system" would contain elements of the following: * Source control. * Dependency tracking. * Build systems (i.e. What to build and how to find things during a build. What is shared? What is local?) * Bug tracking. * Automated Testing procedures. * Release Engineering documentation and procedures. * Tape Construction. * Customer Installation. * A way for users to run different versions of the same software on the same host at the same time.
10. How does CVS differ from RCS?
CVS uses RCS to do much of its work and absolutely all the work of changing the underlying RCS files in the Repository. RCS comprises a set of programs designed to keep track of changes to individual files. Of course, it also allows you to refer to multiple files on the command line, but they are handled by iterating over individual files. There is no pretense of coordinated interaction among groups of files. CVS's main intent is to provide a set of grouping functions that allow you to treat a collection of RCS files as a single object. Of course, CVS also has to do a lot of iteration, but it tries its best to hide that it is doing so. In addition, CVS has some truly group-oriented facets, such as the modules file and the CVS administrative files that refer to a whole directory or module. One group aspect that can be a bit confusing is that a CVS branch is not the same as an RCS branch. To support a CVS branch, CVS uses "tags" (what RCS calls "symbols") and some local state, in addition to RCS branches. Other features offered by CVS that are not supported directly by RCS are 1. Automatic determination of the state of a file, (e.g. modified, up-to-date with the Repository, already tagged with the same string, etc.) which helps in limiting the amount of displayed text you have to wade through to figure out what changed and what to do next. 2. A copy-modify-merge scheme that avoids locking the files and allows simultaneous development on a single file. 3. Serialization of commits. CVS requires you to merge all changes committed (via "update") since you checked out your working copy of the file. Although it is still possible to commit a file filled with old data, it is less likely than when using raw RCS.
