{{{ #!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 the 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 {{{}}}. {{{#!xml }}} = Scenario XML's validated vs the given schema = See [[DASISH/Scenario]] == Responding GET api/user/uid == {{{#!xml }}} == Responding GET api/annotations?link="http://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia"&access=read == The root element below is of type {{{AnnotationInfos}}} (the list of {{{AnnotationInfo}}}). {{{#!xml My client is not in a hurry Nativity Facade Nativity Facade (old site) }}} == Responding GET api/annotations/AIDzzz (example of resolvable target sources) == {{{#!xml Nativity Facade different http://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia#Nativity_Fa.C3.A7ade 20.04.2013 http://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia#Passion_Fa.C3.A7ade 20.04.2013 }}} == Responding GET api/annotations/AIDzyy (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. However, the annotation refers to an obsolete version of the page. Later, having the target source references, the client will ask for cached representations of the obsolete web-page. {{{#!xml Nativity Facade (old page) different http://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia#Nativity_Fa.C3.A7ade 29.01.2010 http://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia#Passion_Fa.C3.A7ade 29.01.2010 }}} == Responding GET api/sources/SIDbbb (example usage for unresolvable target sources) == {{{#!xml }}} === Remarks by Menzo === 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/SIDbbb/cached/CIDtttt/metadata (example usage for unresolvable target sources) == {{{#!xml }}} == Request body for POST api/annotations == 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 CREATE_CACHED_REPRESENTATION http://en.wikipedia.org/wiki/Sagrada_Fam%C3%ADlia#Organ 20.04.2013 }}}