WikiD Update APIs
There are several layers of APIs that get used for updating. Any of them could be accessed directly, but in general it is best to think of the WikiD and OpenURL layers as interoperable APIs and the others as replacable implementation details hidden behind a WikiD OpenURL Community Profile.
WikiD
This update layer is modeled as a wiki "action". WikiD mechanically transforms these wiki-style requests into an OpenURL 1.0-compliant form and hands them off to an OpenURL resolver for processing. Typically, this service is invoked as an HTML FORM ACTION METHOD="POST".
<baseURL>/CollectionWikiPages:NonCollectionTest
?schemaURI=info:sid/localhost:CollectionSimpleSchemas:wiki
&001.raw=test
&action=Create
- CollectionWikiPages:NonCollectionTest: The shorthand collection/item identifer (referent) assigned to the record being edited.
- schemaURI: The CollectionSimpleSchemas or CollectionExternalSchemas identifier indicating the type of record that should be created. (To be honest, I don't know why I added this because this information can be deduced from the CollectionCollection record for the referent.)
- 001.raw: One or more key/value pairs containing the fields of the record to be created. The numeric prefix is a clue to WebEdit indicating the preferred order of elements in the record that will be created. The XSL stylesheet used by WebEdit to transform the data into a native XML form has the option of ignoring these clues. Nevertheless, the numeric prefixes are required, even if they are all the same. The remainder of the key's name should be chosen according to the semantic needs of the styleseheet.
- action: "Create", "Update", or "Delete"
OpenURL update service
This update layer is a thin OpenURL "private data" service that invokes the WebEdit update API before returning the client to an appropriate target page. The OpenURL resolver is located at <baseURL>/resolver. Here is the XML ContextObject that gets generated for the example shown above:
<?xml version="1.0" encoding="UTF-8"?>
<ctx:context-object xmlns:ctx="info:ofi/fmt:xml:xsd:ctx"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="info:ofi/fmt:xml:xsd:ctx
http://www.openurl.info/registry/docs/info:ofi/fmt:xml:xsd:ctx"
timestamp="2006-04-13T11:10:43Z"
version="Z39.88-2004">
<ctx:referent>
<ctx:identifier>info:sid/localhost:CollectionWikiPages:NonCollectionTest</ctx:identifier>
</ctx:referent>
<ctx:referrer>
<ctx:identifier>info:sid/oclc.org:referrer/WikiD</ctx:identifier>
</ctx:referrer>
<ctx:service-type>
<ctx:private-data>
schemaURI=info%3Asid%2Flocalhost%3ACollectionSimpleSchemas%3Awiki&001.raw=test&action=Create
</ctx:private-data>
</ctx:service-type>
<ctx:referring-entity>
<ctx:identifier>http://alcme.oclc.org/wikid/NonCollectionTest</ctx:identifier>
</ctx:referring-entity>
</ctx:context-object>
WebEdit
See WebEdit for general information.
This update layer is a non-standards-based (but lightweight and open-source) web service that takes HTML form submittals, transforms them into a native XML representation, and hands them off to another web service (SRU Record Update in this case) for further processing. In theory, the WikiD and OpenURL service layers could be bypassed in favor of calling the WebEdit layer directly from the HTML FORM, but for various reasons this isn't feasible in the case of WikiD. For example, the addition of a Preview submit button (which WebEdit wouldn't recognize) next to an Update submit button (which WebEdit does recognize) would make this particularly awkward. It would also undermine the philosophy that WikiD is derived from an OpenURL Community Profile and that WebEdit is an implementation detail within that framework.
Furthermore, the Servlet for WebEdit was omitted from the WikiD distribution in favor of having the OpenURL service call the underlying methods directly from code. This is basically because the WebEdit Servlet thinks it knows what type of XML record it should produce from an HTML form submittal, but because WikiD can store arbitrary XML records in its database, the situation isn't quite so straightforward in this case. The workaround was to break WebEdit into two separate method calls. One method transforms HTML form submittals into a target XML record, and the other invokes the SRU Record Update layer. The Servlet blindly calls one after the other, but WikiD needs to step in between to Base64-encode the "native record" and embed it in a metadata record along with selected bits of information to satisfy the SRU Record Update requirement that all records in the database share a common XML Schema. (Although the current WebEdit Servlet doesn't account for this scenario, it could/should be enhanced to support it eventually.) WikiD, then, takes responsibility for knowing that the native record is subordinate to the metadata record. The advantage is that one database can be used to satisfy WikiD's need to store arbitrary XML records.
SRU Record Update
This update layer is a standards-based update protocol (http://srw.cheshire3.org/docs/update/) developed by the SRU Community (http://www.loc.gov/standards/sru/). The web service is located at <baseURL>/WikiDb.localhost/Update.
Parameters to SRU Update are:
<Deposit>
<refID>info:sid/localhost:CollectionWikiPages:NonCollectionTest</refID>
<userName>anonymous</userName>
<collection>CollectionWikiPages</collection>
<mimeType>text/xml</mimeType>
<sort>CollectionWikiPages:NonCollectionTest</sort>
<simpleObject>PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiIHN0YW5kYWxvbmU9InllcyI/Pg0K
PHJlY29yZCB4bWxuczp4c2k9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3Rh
bmNlIiB4bWxucz0iaW5mbzpzaWQvbG9jYWxob3N0OkNvbGxlY3Rpb25TaW1wbGVTY2hlbWFzOndp
a2kiIHhzaTpzY2hlbWFMb2NhdGlvbj0iaW5mbzpzaWQvbG9jYWxob3
N0OkNvbGxlY3Rpb25TaW1w
bGVTY2hlbWFzOndpa2kgaHR0cDovL3lvdW5nLWoub2Eub2NsYy5vcmc6NDM0Mi93aWtpZC9yYXcv
aW5mbzpzaWQvbG9jYWxob3N0OkNvbGxlY3Rpb25TaW1wbGVTY2hlbWFzOndpa2kueHNkIj4NCjxy
YXc+dGVzdDwvcmF3Pg0KPC9yZWNvcmQ+DQo=</simpleObject>
</Deposit>
- refID: The URI assigned to the record
- userName: An identifier for the user who submitted the record
- collection: The local identifier for a collection registered in CollectionCollection
- mimeType: The mime type for the data stored in <simpleObject>
- sort: Text that can be used for SRU sorting and presented in brief results lists.
- simpleObject: A Base64-encoded XML record. WARNING! The XML namespace for this record MUST match the native schemaURI specified in the CollectionCollection registry for <collection>.