Hi all, John: As I was going through my EXE and RC extractors and writing down notes, I thought it would be easier to simply merged that with your document. The result is attached. I've replaced the original Novell's example by generic ones [so we could ultimately provide both source and compiled files with the document]. I've remove the 'boilerplate' examples thinking they were redundant with the real ones, and the file was getting big and a little bit cluttered (but we could certainly put them back). I've added all the types of resources I could think of, following the same approach you took with of the original ones. The text highlighted in yellow are comments, questions, unresolved issues, etc. You'll see that they are many. I'm wondering whether having a specialized namespace for all those winres-specific attributes may be better? Some attributes are needed regardless of the format, like restype or resname, but menu-option, extradata, etc. may be not generic enough or too much. For example: MENUEX requires 3 values not just menu-option, then if we use style and exstyle for the two left, that changes the semantic of style and exstyle, therefore they become more generic and maybe should be named to reflect that? I'm not sure how we can reconcile this line of effort with Gérard's thoughts on the topic. It would make sense to have a unique way of representing winres data. But where is the boundary between representation of 'extracted' data and representation of the data themselves? Is it even necessary to make a distinction in the case of winres? But if not, then the same could be said of any extractable format. ...Just thinking aloud. Cheers, -yves Attachment: wd-xliff-profile-winres.zip Description: Zip compressed data