Hi Kim, > All of these need to be optional, IMO, I wouldn't want to > require too much work from search-builders.
I agree. > > <language /> > > <region /> > > The last should have predefined suggestions in wizards to make > > it more compatible with filtering on values for the enabling/ > > disabling searches. > > That's a good one, what should they default to? "undefined" That way you're not misdirected to disable searches that are language neutral or don't really applu to a specific region. > > <history> > > We have this information in the CVS, and there no use littering > the XML with it... Is there? I think there is. Since the information is only stored in the XML file itself it doesn't waste memory on the client, and being able to track whether you've got the 'right' amaz.xml would be far easier if it identified directly within it. For very complicated searches, some of my searches, and especially those searches that have several people providing input, we need to have 'more tangible' records of changes. I don't think it's necessary to document very minor changes (action url, field names and category for example) in the changelog, but it should be available to people that want to know the difference in their search and one that's 2kb bigger before they apply it. I'm not advocating that it should be required either, just that it should be a defined structure (not necessarily the one I suggested) for those that want to provide this level of documentation. > > <about /> > > What extra information would this provide, that <description/> > and <link/> doesn't? > To me, it seems redundant. I plan on developing a DQSD are of my site, and if you search google for DQSD - you'll see quite a few others have too. Though I still intend to commit most of my changes into CVS, I will also be providing the searches from my site directly - just like you. It doesn't appear you've got any functionality on your own site that you're allowing people to search with your searches - so I can't use you as an example. Myself, the "ct" (content-type) search goes to my site and queries a db there. I would like to provide a page 'just for DQSD users' that explained in greater details how to use the ct search with my site. The <link> tag would ideally point to http://ReliableAnswers.com/contenttype/CType.asp - which is a 'web interface' for the same thing the 'basic' search does (gg would link to www.google.com, even though it's possible to search news.google.com), but the <about> tag would link to a page that was created explicitly to amount to something of an extended help file. A link incorporating the <about> tag does not necessarily have to be exposed (though it would be nice to have in the "?" results) - just there for user or programmatic access. > This might be interesting. It's "cleaner" than the existing > <created_by/>, so I propose we replace <created_by/> with > <generator />. Of course, the DQSD wizard would have to be > updated, but I can do that if we reach consensus. > There's no logic based on <created_by/>, is there? Nope. It's pretty well free text (another reason why I like the <history> tag). My web-based search creator (no guarantees on when it will be available) will have the ability to edit existing searches. By providing for a structured history/generator data we will be more capable of programmatically editing an existing search. (Yes, I'm being selfish, I *do* use DQSD for myself!) > > <requirements /> > > If we can use this for diagnosing errors run-time, it seems > like a good idea. I didn't even think about that, but yes, that'd be good too. We could add additional children to it like (for an MS-Access, any version, search): <requirements> This search requires Microsoft Access to be installed on the system. <file count="1"> <file>%Program Files%\Microsoft Office\Office\msaccess.exe</file> <file>%Program Files%\Microsoft Office\Office10\msaccess.exe</file> </file> </requirements> I recognize that those path names are english-only, and I don't know how we'd ensure that it still operated correctly on non-english systems (perhaps the default behaviour would be t just run the search and IF an error occurs display the requirements data instead of some cryptic error report). For a search that relies on another search to be enabled: <requirements> This search relies on the 'vbsx' search to be present and enabled on your system. <search>vbsx.xml</search> </requirements> For a search that requires login details variables to be set: <requirements> This search requires two variables to be stored in your preferences to provide the ability to login to your email. <variable>hotmailusername</variable> <variable>hotmailpassword</variable> </requirements> A search that requires a single variable: <requirements> This search requires a variables to be stored in your preferences to use the Google API services. <variable>googleLicenseKey</variable> </requirements> Regards, Shawn K. Hall http://ReliableAnswers.com/ '// ======================================================== Faith is simply taking God at his Word. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ DQSD-Devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dqsd-devel
