| 29 | | Format (syntax) [[BR]] |
| 30 | | Contents (semantics) [[BR]] |
| 31 | | Point-of-view [[BR]] |
| 32 | | Structure [[BR]] |
| | 29 | |
| | 30 | Format (syntax) [[BR]] |
| | 31 | Goal remains: one data model for GENI [[BR]] |
| | 32 | Assume: transfer format is XML record (file) [[BR]] |
| | 33 | Have example in XML-like format, and schema/types in RelaxNG [[BR]] |
| | 34 | Need: first software to generate (and consume) MDODs [[BR]] |
| | 35 | |
| | 36 | Contents (semantics) [[BR]] |
| | 37 | Few required elements, many optional elements [[BR]] |
| | 38 | To meet use cases in arch document, sec 4.5 [[BR]] |
| | 39 | Want one-for-one mapping to key elements in current tools (started: perfSONAR; GENI rspec) [[BR]] |
| | 40 | |
| | 41 | Point-of-view [[BR]] |
| | 42 | Often global; therefore includes locators for data objects; must be updated as objects are copied, moved [[BR]] |
| | 43 | Sometimes associated; need to understand [[BR]] |
| | 44 | Should we consider: storing MDODs in global, GENI registry? [[BR]] |
| | 45 | |
| | 46 | Structure [[BR]] |
| | 47 | identifier(s) [[BR]] |
| | 48 | descriptor(s) [[BR]] |
| | 49 | holder(s) [[BR]] |
