Changes between Version 114 and Version 115 of DASISH/XSD and XML

Timestamp:

08/26/13 15:26:51 (11 years ago)

Author:

olhsha

Comment:

--

DASISH/XSD and XML

@@ -534 +534 @@
 </annotationCollection>
 }}}
+
+
  
 By the way, speaking of diverse "JAXB plural issues", there were some hints on the web regarding (inline and external) Java binding customization for JAXB, - it might be that this would also be a viable solution approach. Maybe this thread is worth checking as well: http://stackoverflow.com/questions/11943487/please-advise-the-best-pattern-for-serialising-jaxb-lists?
 
+Oha: we agree.  See also the updated comments for the ticket 348.
+
 As regards all future schema updates, please make sure to remember to update all available scenario xml documents on trac.clarin.eu accordingly, and preferably, with as little delay as possible. It might also be a good idea to validate all of these documents against the revised schema with a reliable XML parser like e.g. the Xerces-J XML parser. Also, if you like, you can check by validating some of our current "real-life" mock xml documents that we have been using recently for client development ([source:DASISH/t5.6/client/trunk/chrome/markingcollection/content/markingcollection/annotator-service/test/mockjax/mocks]).
+
+Olha: sure. We have not make any changes yet (before getting you opinion). Unfortunately, I will be away 27/08 - 14/09 due to urgent family circumstances. I hope that we can wait till I'm back. 
 
 === Resolution ===
@@ -556 +562 @@
 Could you please rethink whether we actually need to keep this concept in the schema document, DASISH-schema.xsd? This decision also has consequences for how the behavior of the client needs to be tuned (cf. [source:DASISH/t5.6/client/trunk/chrome/markingcollection/content/markingcollection/annotator-service/test/mockjax/mocks POST/GET] mock docs named above).
 
-=== Resolution ===
-
-The schema stays intact.  For the backend-code: the server should check if the source is indeed new, see  https://trac.clarin.eu/ticket/362 for more detail.
+Olha: we agree with you. See resolution below.
+
+=== Resolution ===
+
+The schema must be simplified. It is up to server to decide if a  source is new or old. See ticket  https://trac.clarin.eu/ticket/362 for more detail.
 
 
@@ -570 +578 @@
 ''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?
 
+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. 
+
+ "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.
+
+Also, the ticket 371 mentioned below is fixed.
+
 === Resolution ===
 
@@ -576 +590 @@
 Moreover, all {{{{CachedIdentifier, VersionIdentifier, SourceIdentifier, AnnotationIdentifier, NotebookIdentifier, UserIdentifier}}} must be removed. We will be using just  UUID type
 for all  identifiers of any sort of resource. E.g.  UserIdentifier userIdentifier = New UserIdentifier("00000000-0000-0000-0000-000000000003") will be replaced with
-UUID userIdentifer = UUID.fromString("00000000-0000-0000-0000-000000000003"). It is the ticket  https://trac.clarin.eu/ticket/371
+UUID userIdentifer = UUID.fromString("00000000-0000-0000-0000-000000000003"). It is the ticket  https://trac.clarin.eu/ticket/371.  
+
+
 
 == Body: must be some serialization/deserialization mechanism ==
@@ -593 +609 @@
 ''Stephanie:'' It might be preferable to abandon the helper methods in favor of using JAXB's marshal() and unmarshal() methods together with a(n) {{{Marshaller}}} / {{{Unmarshaller}}} object. Can JAXB's {{{ObjectFactory}}} methods be of any use as an alternative way to access XML data? Furthermore, you might want to have a look at Javax.xml.bind.JAXBIntrospector.getValue(Object jaxbElement). Please see: http://www.tutorialspoint.com/java/xml/; http://www.oracle.com/technetwork/articles/javase/index-140168.html; http://docs.oracle.com/javase/tutorial/jaxb/intro/index.html; http://jaxb.java.net/tutorial/ - in case you haven't come across these web resources before.
 
+
+Olha: Yes it will be replaced. t. When I wrote the code I needed some quick solution that would provide me with the serialized version. Once we decide to use Marchaller and Unmarchaller, I will remove helpers.  
 
 == Source ==
@@ -655 +673 @@
 [[BR]][[BR]]
 ''Stephanie:'' When removing the URI attribute for lists of resources, please make sure that the integrity of the references is still guaranteed.
+
+Olha: lists are not stored in the DB but generated by the backend on the fly when they are needed. For instance, once the client want to GET an annotation (which schema contains the lists of source-infos), the backend looks up a joint table "annotations_resources" and the table "source"  and  generate a list of resources for the annotation.
+