08-07-2014 04:00 PM
I was answering a question over on stackoverflow (sas ods - Grouping plots and tables using a BY statement in SAS - Stack Overflow for reference) that involved using PROC DOCUMENT to manipulate a report, and realized something that was frustrating me: while I could figure out how to do it with code, and could imagine writing code to write said code, what I felt like was my early days of writing automatic formats: writing value statements. Once I learned CNTLIN, I never again returned to the value statements, because it's so much less clunky.
ODS DOCUMENT/PROC DOCUMENT seems like it should very easily have that sort of interface (in addition to the programming environment version): the ability to output a stored ODS DOCUMENT as a dataset, manipulate it in the data step, and then import it back. This would probably just be exporting/importing the labels in the hierarchy, not the actual data that produces the report (not the tables/graphs), of course.
Is this possible currently? I dug around and didn't see any obvious way (the dataset import for example seems to just print out the contents of the dataset).
If not, is this something that could possibly be implemented (ie, if I make a feature request), or do the behind-the-scenes of ODS DOCUMENT make this impossible to imagine?
08-07-2014 08:13 PM
I am not sure that what you describe is possible with ODS DOCUMENT. PROC DOCUMENT exists to write code that will manipulate the ODS DOCUMENT store and rearrange and replay the output objects. So to the extent that you can write a SAS macro program to write the PROC DOCUMENT code for you (since the PROC DOCUMENT code can be lengthy), I'm not sure that you really need what you describe. But at any rate, I'm having a hard time envisioning the usage case for what you describe. If I have to manipulate the document store with a programming language, writing the PROC DOCUMENT code seems just as good to me as having to learn another language for manipulating the objects in the document store in a DATA step program.
The only reason I didn't show a "macrotized" approach in my paper about ODS DOCUMENT was that if I'm writing about one complex thing, I tend not to complicate it by adding another complex thing into the mix. Besides, the main principle of SAS Macro programming is that you have a working SAS program to start. So once I write the ODS DOCUMENT store and then my PROC DOCUMENT statements and have a working program and I understand that code very well, then "macrotizing" the PROC DOCUMENT code is fairly straightforward (in my opinion).
But that's just my .02 on the subject. If you want to make a ballot item, then why not do that and see how the community of users responds to the idea.
08-07-2014 11:31 PM
Certainly understand not putting the macro in the paper (and wasn't suggesting it should've been). My issue is precisely the converse of what you said: I don't see why it should be necessary to learn another language (PROC DOCUMENT), when the structure could be trivially represented in a dataset form, and as such made accessible to data step manipulations (which are simple, powerful, and most SAS programmers will find them comfortable to do).
In your example in your paper, if there were a dataset, it would've been easy to simply say:
length path $100;
input path $;
path = '\'||catx('\',scan(path,1,'\'),scan(path,3,'\'),scan(path,2,'\'),scan(path,4,'\'));
proc document update=work.mydoc cntlin=to_ods_document;
Seems easier than having to write a macro to do all of that '^^' stuff. I imagine the dataset would be richer than just a path variable, but honestly just a path variable would be entirely fine by me.
Anyway, I was largely asking to see if this was possible now in case I'd missed something; as it seems it's not, I'll make a sasware ballot suggestion and see how many ODS DOCUMENT users would find it useful (or how many there are?). For me not having dataset-level access is a big barrier to using it - not sure if that's true elsewhere but worth seeing.