Hi there, there might be good reasons (as mentioned here) to not like XML but its mature and rich technology stack (XSLT, XPath/XQuery, Schematron, RelaxNG), available tooling (Mapforce, XML Spy...) and support (Most major database vendors...) makes it a working solution in many use-cases. I really can't say that we are unhappy with it at our persistence layer (though one of my master students currently investigates the use of intersystems cach? as an alternative...I'm not quite sure if AQL will be possible in an "easy" way as in XML databases ) Of course, I like the elegance of Json but there is plenty of work to do until it's getting a real substitute (if at all)...
Best, Birger Am 16.04.2015 um 09:48 schrieb Diego Bosc?: > In fact, JSON-Schema is only lacking a more detailed typing system to > replace ADL :) > > 2015-04-16 9:29 GMT+02:00 Thomas Beale <thomas.beale at oceaninformatics.com>: >> On 16/04/2015 06:46, Bert Verhees wrote: >>> >>>>> I think it is a stupid rule in the XML-Schema standard. >>>> >>>> I just hit this in doing the AOM2 schema. It's a completely senseless >>>> rule, clearly a hangover from 'document' thinking - nothing to do with >>>> 'data' thinking. I ended up replacing <sequence> with. >>>> >>>> <xs:choice maxOccurs="unbounded"> >>> >>> It is a poor man's choice, because of the side-effects. >>> The "choice"-constraint makes the engine ignore the minOccurs/maxOccurs >>> constraints in the elements under the choice element. >>> >>>> I have to say, XML-schema based data looks extremely unattractive as a >>>> basis for anything except data exchange. I wouldn't try to implement >>>> anything important inside a system with it, you are too compromised in too >>>> many ways. >>> >>> It is also used, as I wrote yesterday, to tell an XML-database how, in a >>> specific namespace, the data are arranged, in that way the database can >>> auto-create indexes, etc. >>> There is no other way to communicate the structure of XML-documents, and >>> even if we found another way, or invented it ourselves, we still would need >>> a broad acceptation. >> >> We still need some kind of schema for XML docs/ messages, but I would not >> even think of making any persistence be based on XML, especially not XML >> schema. Probably Relax NG would have been the better one for messages etc. >> >> Keep XML at the boundaries, that's the key to happiness! I guess JSON with >> its own schema will replace it in the next couple of years. >> >> - thomas >> >> >> _______________________________________________ >> openEHR-technical mailing list >> openEHR-technical at lists.openehr.org >> http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at lists.openehr.org > http://lists.openehr.org/mailman/listinfo/openehr-technical_lists.openehr.org -- *Birger Haarbrandt, M.Sc.* Peter L. Reichertz Institut f?r Medizinische Informatik Technische Universit?t Braunschweig und Medizinische Hochschule Hannover M?hlenpfordtstra?e 23 D-38106 Braunschweig T +49 (0)531 391-2129 F +49 (0)531 391-9502 birger.haarbrandt at plri.de http://www.plri.de -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/pipermail/openehr-technical_lists.openehr.org/attachments/20150416/85cd29b2/attachment.html>
