Hi Gilles,
Thank you for having a look into my proposal and giving your valuable feedback. The proposal I sent was a brief outline of my project. I kept it short as I have been advised to do so. I have given answers to some of your queries with respect to the .x3d format below.
 

The X3D format provides an XML code as an source code. This XML script can be used to extract information of the file. There are functions like getScreenshot() which return a .png file of the 3D image. There are also functions to manipulate the camera views (given in the API documentation of x3d). Using these views we can set a standard view and use the getScreenshot() function to get a .png file.
How getScreenshot() actually works is :
" getScreenshot()
Returns:    URL to image
Returns a Base64 encoded data URI containing png image consisting of the current rendering. The browser will interpret this as a PNG image and display it. A list of browsers which support data URI can be found here. The following example illustrates the usage:
    var url = ...runtime.getScreenshot();
    var img = document.createElement("img");
    img.src = url;
    ...
"
This is taken from the documentation of x3d.

Now, to texture. Every x3d file has a texture map. This map contains Background, ImageTexture, MovieTexture, MultiTexture, and PixelTexture. In all cases, texture maps are defined by 2D images that contain an array of colour values describing the texture. If we want detailled texture we can rebuild the texture using this map. The only problem I see here is that this process might not be feasible in terms of memory and speed. Maybe it will work out. Otherwise I believe even the screenshot will retain some texture and we can use that as well. The good thing here is that the texture map provided by x3d has a format in terms of PNG pixels which shall make compatibility easy.
Some more details on texture maps :
Texture maps are defined in a 2D coordinate system (s, t) that ranges from [0.0, 1.0] in both directions. The bottom edge of the image corresponds to the S-axis of the texture map, and left edge of the image corresponds to the T-axis of the texture map. The lower-left pixel of the image corresponds to s=0, t=0, and the top-right pixel of the image corresponds to s=1, t=1. Texture maps may be viewed as two dimensional colour functions that, given an (s, t) coordinate, return a colour value colour(s, t).

I have not studied COLLADA in much depth and will get back to you on it in some time. For the moment the advantages of using x3d seem to be :
-> First of all x3d seems to be pretty well documented and shall be easy to go in even further depth.

-> All x3d files have a source code in xml which I have no problems with.

->Further, since we can get all contents of the file in xml it shall be easy to validate it as well.

-> Functions like getScreenShot() should make our process comparitively easy.

->Also, x3d files have meta statements. These meta statements provide information of the x3d scene as a whole. We can directly take this information from these meta statements.

Another thing that I found which might be relevant could be -

"Blender export :
Converting Blender scenes into X3DOM webpages is pretty simple: Blender already supports direct X3D export even so there are some issues. Blender Version 2.4 seems to export some more nodes (e.g. lights), but in general it works. We will explore this more in the future, but an exported X3D file ( may afterwards be easily be integrated into an HTML webpage using X3DOM.
Just finish your model in Blender and export to x3d file format.
There are two ways to get your X3D data into the HTML page, and both include no coding at all:
1. Two-file solution, link the X3D-file
Just use a very simple X3D scene in your HTML file, which, more or less, only includes an <inline> node. This nodes references and asynchronously downloads the X3D file. Therefore you need a real web server (e.g. Apache) running while using <inline> nodes in X3DOM.
2. One-file solution, embed the X3D data inside of the HTML page
You can embed the X3D file by hand in a (X)HTML page, but this may include some hand-tweaking. Better use the aopt-converter described in Generic 3D data conversion. This can be done offline with a single command:
aopt -i horse.x3d -N horse.html (horse.x3d is an x3d file being converted into an html one)
You also may use the converter online. Just open horse.x3d with your favorite text editor and paste it into the source text field. Choose XML encoding (X3D) as input type and HTML5 encoded webpage as output type and press the Convert encoding button."
Even though I am more sure about the former method, I am mentioning this here as there was some discussion on the bug related to blender files. If this works then using x3d we can incorporate blender files as well.

I would be highly grateful if you could provide me with further insights into this project.

Regards,

Umang