Changes between Version 120 and Version 121 of DASISH/XSD and XML


Ignore:
Timestamp:
08/26/13 15:46:01 (11 years ago)
Author:
twagoo
Comment:

added comment on cached representation question and extended answer on external id issue

Legend:

Unmodified
Added
Removed
Modified

  • DASISH/XSD and XML

    v120 v121  
    578578''Stephanie:'' Apropos this subject, could you please clarify whether you intend to use "external-id (Ticket #362: externalID, see even discussion topic above)" for the database only? You use the wording "For the time being", which made us wonder whether the statement "URI is external_id" will be true even in the longer perspective, or, if not, where / how the externalID is going to be put in from the schema side, an thus within the context of the resulting, serialized xml documents? Furthermore, why is the nomenclature "external_id" used? Won't the value of URI always be an internal id, like e.g. http://dasish.eu/annotations/AID20130808114716, that needs to be created and set via a corresponding backend functionality?
    579579
    580 ''Olha'': The term "external_id"  comes from the Data Base  and is used for communication with the client.  It is a string which satisfies UUID-format, e.g. "00000000-0000-0000-0000-000000000003". The URI in the xsd is of the form  like you mentioned above  e.g. http://dasish.eu/annotations/00000000-0000-0000-0000-000000000003. An external Id is generated by the backend whenever a resource is recognized as new in the  corresponding "add"-method. It is sent to the client as a respond to the "Add" request.
     580''Olha'': The term "external_id"  comes from the Data Base  and is used for communication with the client.  It is a string which satisfies UUID-format, e.g. "00000000-0000-0000-0000-000000000003". The URI in the xsd is of the form  like you mentioned above  e.g. http://dasish.eu/annotations/00000000-0000-0000-0000-000000000003. An external Id is generated by the backend whenever a resource is recognized as new in the  corresponding "add"-method. It is sent to the client as a respond to the "Add" request. Just to be sure, we definitely intend to keep it this way although there should be no need for the client to be aware of the conceptual distinction between 'external id' and the URI, in other words the latter can be considered the public identifier for the client.
    581581
    582582 "Internal_id" in the database is not visible to a client.  It is "next-in-the-table"  number generated by the database whenever the corresponding resource is added. It is a primary key of the resource. It is used for joint tables (e.g. when you connect an annotation to a source) and for quick search by key, since it is just a number, not a string.
    … …  
    636636''Stephanie:'' Please define what data needs to be sent from the client regarding cached representations (the HTML markup, any css files, images, ...?). In Wired-Marker, what is called "cache" is a locally saved copy of the HTML markup plus a css file with content aggregated from the css files used by the original website (cf. DiscussionPage: Answer 1 on Versioning).
    637637
     638''Twan:'' no specific format is expected but in the current specification 'a cached representation' matches up with a single file. So according to this the client should choose a representation that can be represented as a single file or use some method of wrapping multiple files up into a single entity. Apart from that, the exact nature of the cached representation is taken to be client specific, so you can choose what format suits the plugin best. If the current single file situation really turns out to be problematic, let us know and we could consider alternative solutions that do support grouping multiple files together as a single cached representation entity.
    638639== Version ==
    639640