download as a pdf - Southern California Coastal Ocean Observing ...

Part III. Appendix 2: Data TransportXML is not without its awkward aspects, though. For example, it is still not entirely settled how oneshould include data that the XML parser should not inspect within an XML document. One solutionseems to be not to include it at all, but to include a URL that points to the data, which could befetched by a non-XML mechanism. Another approach is to use a multi-part MIME document as anadditional envelope around the XML document and to include as well the binary data as anotheroccupant of the envelope. The IOOS DMAC-SC DTT will have to keep an eye on the developingstandards relevant to this matter, and a planning activity needs to be set in motion that will trackthe development of non-parsed XML content. When (if) a standard emerges, then the planningactivity will make a recommendation on whether the data access protocol should be modified touse the standard.Data DiscoveryA critical component of the overall data system is the ability to locate data within it. Data discoveryis being addressed by another subgroup of the DMAC-SC, but there are critical areas of overlapbetween these two groups. The perceived difficulty associated with populating data discovery servicesand the resistance by the data collection community to documentation of data are issues thatneed to be addressed not only to provide for data discovery, but to utilize data appropriately in thefuture. Deploying a system that allows as much automation as possible in the area of documentationis a requirement, along with educating the data-collection community and providing consultingservices that will ease the burden of documentation. To address these issues, we believe that thedata discovery portion of the system must be intimately coupled with the data access portion andthat this coupling must be as automated as possible.FUNCTIONAL REQUIREMENTSThis section discusses “the core,” that is, the functionalities that the IOOS Data Transport System’sdesign and implementation guarantees to make available to any user of the system. Many of thesefunctionalities must be available to every client/server pair. Others, however, may be so implementedthat they require the participation of an intermediary, such as a specially outfitted server which,nevertheless, would be available to every system user.The motivation behind communication protocols tends to be the desire to provide the most functionalityand convenience to the greatest number of users for the lowest overhead imposed uponthe parties individually and in total. The design goal of bringing data transfer functions to all IOOSclients and yet not requiring them or all the IOOS servers to become complex (“thick”) may beachieved in part by giving the responsibility for fulfilling certain kinds of client requests to just afew servers. The organization of this section reflects this dichotomy:153