{{{ #!html

Contents

}}} [[PageOutline(1-3, , inline)]] {{{ #!comment Obviously, your page starts below this block }}} = XSD Schema = The xsd schema is designed according to the following paradigm: -- There are five xsd-types corresponding five sorts of resources in DASISH: CachedRepresentation, Source, User, Annotation, Notebook. -- Each of these types has an obligatory attribute "URI" which contains DASISH identifier pointing to the location of the resource on DASISH server. -- There are five lists-of-reference types: CachedRepresentations, Sources, Users, Annotations, Notebooks. Their names are just plural English forms of the corresponding types. -- There five corresponding resource-infor types: CachedRepresentationInfo, SourceInfo, UserInfo, AnnotationInfo, NotebookInfo. They contain reference to the corresponding resource plus the most important information about the resource. -- There five corresponding list-of-resource-infor types: CachedRepresentationInfos, SourceInfos, UserInfos, AnnotationInfos, NotebookInfos. There is a number of auxiliary types as well. A commonly-used one is ResourceREF which contains the attribute "ref" of type "xs:anyURI". It allows to have announce elements-references and avoid mixing-them-up with elements-resources, without adding REF to the name. For instance {{{ }}} = Scenario XML's validated vs the given schema = See [[DASISH/Scenario]] == Responding GET api/user/uid == {{{#!xml ID01 }}} == Responding GET api/annotations?source="http://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia"&access=read == {{{#!xml My client is not in a hurry Nativity Facade Nativity Facade (old site) }}} == Responding GET api/annotations/AID02 (example usage for resolvable target sources) == {{{#!xml Nativity Facade different http://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia#Nativity_Fa.C3.A7ade 5.0 http://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia#Passion_Fa.C3.A7ade 5.0 }}} == Responding GET api/annotations/AID01 (example usage for unresolvable target sources) == The respond for an annotation with unresolved target sources and the respond for an annotation with resolved target sources (see above) are both instances of the same schema element. {{{#!xml Nativity Facade (old site) different http://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia#Nativity_Fa.C3.A7ade 1.0 http://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia#Passion_Fa.C3.A7ade 1.0 }}} == Responding GET api/annotations/AID01/sources (example usage for unresolvable target sources) == {{{#!xml http://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia#Nativity_Fa.C3.A7ade 1.0 http://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia#Passion_Fa.C3.A7ade 1.0 }}} === Remarks by Menzo === The versions list contains the version you looking at as well, e.g., the version list of SID005 consists of SID005 and SID015. Is this so because the list is ordered and we can determine the position of the version under consideration? For very dynamic and popular target sources the version list might become big, that could be a reason to move it to a separate call. Actually we have already GET api/sources//versions, so I would leave them out here. === Olha's comment:=== We have agreed earlier that the list of versions would include all the "siblings", include the source itself.Are there alternative ways to get all the siblings of a given source? == Responding GET api/sources/SID05/cached/CID005A/metadata (example usage for unresolvable target sources) == {{{#!xml }}} == Request body for POST api/annotations == {{{#!xml Organ installed in 2010 http://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia#Organ 5.0 }}} The version of the POST with an unknown target source, signalling the client to provide a cached representation for it: {{{#!xml Organ installed in 2010 http://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia#Organ 5.0 CREATE_CACHED_REPRESENTATION }}}