I'm glad you found some use for the [font=courier new]Home.xml[/font] export. Do you plan to make your script available to the public? That would be a nice way to import a home in Blender with lights.

I don't know whether the HTML viewer will support some lighting, but you can already get in [font=courier new]Home.xml[/font] file the light information you look for by changing some flags in the plug-in source code included in the sh3p file (or reusing plug-in classes in an other plug-in). The easiest way should be to remove [font=courier new]HomeXMLFileRecorder.INCLUDE_VIEWER_DATA[/font] flag (and [font=courier new]HomeXMLFileRecorder.REDUCE_IMAGES[/font] if you don't want images to be resized) in the [font=courier new]getHomeRecorder[/font] method the end of the [font=courier new]ExportHTML5PluginAction[/font] inner class of [font=courier new]com.eteks.sweethome3d.plugin.exporthtml5.ExportHTML5Plugin[/font]. Then, rebuild the plug-in with the help of Plug-in developer's guide.

The XML format of [font=courier new]Home.xml[/font] shouldn't change in the future, it will even become part of the updated format of Sweet Home 3D files. In the coming versions 5.x, the idea is to include the [font=courier new]Home.xml[/font] file along with the existing [font=courier new]Home[/font] Java serialized entry in .sh3d files + the ability to parse both entries even if they describe the same [font=courier new]com.eteks.sweethome3d.model.Home[/font] instance. Then probably in versions 6+, the default Sweet Home 3D files will have a .sh3x extension and use a file format that will contain a [font=courier new]Home.xml[/font] entry but no [font=courier new]Home[/font] entry, to avoid slowing down Save operation. This transition will help users to read .sh3x files even with Sweet Home 3D version 5.3 and superior. Of course, the ability to read [font=courier new]Home[/font] Java serialized entry included in .sh3d files will be kept to be able to read all files made with previous versions of Sweet Home 3D.
The XML writer added to Sweet Home 3D 5.3 will be very close to the one in Export to HTML5 plug-in, using the same elements and attributes syntax when its [font=courier new]INCLUDE_VIEWER_DATA[/font] flag is not set. Why only "very close" and not "the same as"? Because the plug-in needs to simplify the exported data to match SweetHome3DJS features, i.e. its inability to read 3D models at 3DS and DAE format as well as to compute walls and rooms in 3D. Quickly said, at the moment, the plug-in is "only" able to read 3D models at OBJ+MTL format listed in [font=courier new]Home.xml[/font] and place them at the good location. Walls, floors, ceilings, holes in the ground and 3D labels are all precomputed by the plug-in in the [font=courier new]HomeStructure/Home.obj[/font] entry which is displayed as one 3D object by SweetHome3DJS. This structure file and exporting only in OBJ format is not needed in Sweet Home 3D itself, that's why its XML writer will not perform these operations but will keep the same XML syntax, except for the [font=courier new]structure[/font] attribute of the [font=courier new]home[/font].
From the various tests I run with Blender, it seems that Blender supports better OBJ+MTL format than 3DS and DAE formats (but maybe it was improved recently). Blender is of course unable to compute in 3D the walls and rooms of a Sweet Home 3D file. So I guess that the format I chose for SweetHome3DJS is the best choice for Blender too, and you would prefer that the way 3D models and home structure are exported won't change! I'll keep that in mind and if needed I'll create an other Export to XML + OBJ plug-in. That could even become a Save option in Sweet Home 3D if this format becomes really useful for many people. Keep also in mind that DAE/Collada format is also able to store lights, so if you need only OBJ files + lights, it could be more logical to add Export to DAE format option (even if this will require more work from me).