currently SWS only allow registration searches *by section* for the current quarter. we had to implement this feature in this manner due to performance issues however we can work in fixing this problem if there is enough demand on campus for this

Some clients (groups service, canvas, for example) need to see hidden courses in both curriculum and section searches. Suggest you add a parameter on the query string to activate an 'include ts_omit sections' query.

We're preparing the paperwork to request FWS authorization for one of our applications. Relative to other UW services, it's a fairly rigorous process, considering we only want org code and org name data, neither of which seems to be of a sensitive nature.

Since we're trying to follow best practices in terms of not re-using already approved certs across multiple applications, I anticipate we'll have to go through the approval process at least a few times.

It would be nice if we could self-regulate in exchange for a less rigorous authorization process - i.e. don't let us see sensitive stuff, and therefore don't require signatures, application design review, etc.

The PWS model seems to work well from my outside perspective - an online form is available to request EDS data, and approval is pretty quick and simple if you don't require student data.

Maybe other services would benefit from this same recommendation? I'm only picking on FWS because it's the one I'm working with right now.

We're preparing the paperwork to request FWS authorization for one of our applications. Relative to other UW services, it's a fairly rigorous process, considering we only want org code and org name data, neither of which seems to be of a sensitive nature.

Since we're trying to follow best practices in terms of not re-using already approved certs across multiple applications, I anticipate we'll have to go through the approval process at least a few times.

It would be nice if we could self-regulate in exchange for a less rigorous authorization process - i.e. don't let us see sensitive stuff,…

I have code that is generic enough that others could use it, but there isn't a place to share code.

A sourceforge/launchpad/codeplex-like area (hosted by UW or just a special tag for UW Web Services projects at either site) would be great. A forum would allow for knowledge capture, collaboration, and deduplication of efforts.

There are lots of core "Master Data" bits and pieces that need to be input into form fields in systems all over campus. Things like EID, budget number, org code, object/subobject codes, PCA codes, course numbers...the list is almost infinite. What the end-user often faces is a field that requires a key or code to be entered, but only knows the name or description. They then need to lookup it up somehow. Ideally the lookup function should be close coupled to the data entry field

There should be a standard protocol for writing lookup services so that developers can quickly write them into any application. The app sends you the entity and part of a name, you send back the critical key/code/id#. That's all.

I'm not submitting any particular item to look up, but rather the idea that there should be a standard protocol for all such simple lookups.

There are lots of core "Master Data" bits and pieces that need to be input into form fields in systems all over campus. Things like EID, budget number, org code, object/subobject codes, PCA codes, course numbers...the list is almost infinite. What the end-user often faces is a field that requires a key or code to be entered, but only knows the name or description. They then need to lookup it up somehow. Ideally the lookup function should be close coupled to the data entry field

There should be a standard protocol for writing lookup services so that developers can quickly…

a central metadata repository is a big project that folks in uwit have been talking about. we’ll look for some smaller bits that we could do within the web services to provide some value in the meantime

It now contains the catalog course description (good!). But adding these:
http://www.washington.edu/students/icd/would allow devs to use all available course data. The new course catalog search using SWS can't fully replace the old Google-based search until it has access to ICDs.

It would be useful to have an API which exposes the required / optional material lists for courses. The basics would be books titles, isbn, and if they are required or not. Currently this information is not available at all through the UW, and must be retrieved from the U Bookstore (which is an independent entity).

Provide a web service that allows access to the UW Online Work/Leave System (OWLS) data for employee schedules and available leave time.
Currently OWLS is a read only web interface for UW employees, forcing departments to implement their own systems for employees to request and get approval for leave time. This means that departments either have a cumbersome wasteful paper based system, or they implement a web based system where the schedule for every employee must be manually added into the system.

As a admin assistant for faculty, I constantly have to go to the SDB to look up add codes, then send them to faculty. The printed ones get lost by faculty. It would be great if the faculty had access to add codes on the teaching section on MyUW.

ASTRA would like to get all of it's student application related Span of Control values out of SWS so that the DTS job that pulls span of control values from SDB can be retired. The only SOC type that is being retrieved from SDB that is not available in SWS is "Major".

This service would be usable by the Groups Web Service provisioner for maintaining organizational groups. Given a budget number, we'd need the EIN's of employees whose current (active, inactive) apptDeptBudgetNbr matches. Or whose HomeDeptBudgetNbr matches. Or whose DistBudgetNbr matches. Or whose (Appt, Home, Dist) budget nbr is in a particular Org Code.
Whew!

There are a number of attributes -- particularly for student resources -- that depend on business logic that isn't well-defined across campus. The most famous example of this is GPA, which must be calculated based on a number of different fields, taking into account a number of caveats about different types of courses, etc. To make matters worse, the business logic that defines this calculation is not well-documented (as far as I know) and results in potentially different results in different applications that may or may not properly calculate the GPA using the same rules of the registrar's office. Whenever possible, these business rules should be formalized and encoded into the web service so that the calculated value is returned in the resource payload.

Another example here is class standing (e.g., Freshman, Sophomore, etc.). When a student graduates, their class standing, according to UW systems, remains as "Senior" because technically that is the only valid value at that moment. Until a student becomes a graduate student, there is no other option in the class codes that can signify "recently graduated" or something similar. Thus, in our application, we check to see if this student has any valid degrees AND they have a class standing of "4" (senior) and return "Graduated <Quarter>" if so. The web service should either provide information in a practical format, or at least provide me with the information I need to easily display the data in a useful way without requiring one or more additional calls to other resources just to provide data in a way that makes practical sense.

There are a number of attributes -- particularly for student resources -- that depend on business logic that isn't well-defined across campus. The most famous example of this is GPA, which must be calculated based on a number of different fields, taking into account a number of caveats about different types of courses, etc. To make matters worse, the business logic that defines this calculation is not well-documented (as far as I know) and results in potentially different results in different applications that may or may not properly calculate the GPA using the same rules of the registrar's office. Whenever…

We are in the process of developing an online form for services requested from Disability Resources for Students. Most requests require that students provide us with their entire class schedule, so it would be great if that information was already populated for them based on thier NetID.