On Mon, Feb 4, 2019 at 3:22 PM Neil Van Dyke <n...@neilvandyke.org> wrote:
> BTW, you *could* also do both XML and JSON. For example: for some Web > services, coming from a very complicated data model, IIRC, the > engineering process scenario was something like originally the > requirement was for XML, and then JSON was added as a requirement, and > additional services were added at some point, and engineering resources > were tight. What I ended up doing, that time, was defining a conceptual > mapping from a subset of XML to JSON encoding, so that a programmer > wrote the code to construct the XML message, and got JSON for free. > I haven't really used it, but Greg Hendershott has a package flexpr <https://docs.racket-lang.org/flexpr/index.html> that defines a subset of jsexpr <https://docs.racket-lang.org/json/index.html#%28def._%28%28lib._json%2Fmain..rkt%29._jsexpr~3f%29%29>s that can also be converted to x-expressions. You can see many ways to do something like this, and your implementation > might involve a DSL (perhaps in terms of the data model also used by > your documentation, and your DSL can even generate Scribble for the XML > and JSON interface specs for the documentation, separate from any Racket > API documentation). > For Digital Ricoeur, I have in fact made a DSL to express our project-specific requirements for XML documents. (We start with an external XML standard, but we use only a minimal subset of the standard and add additional requirements very specific to our project—e.g. there must be an author with an xml:id attribute of "ricoeur".) The DSL generates Scribble documentation and also defines our internal representation of the documents, including conversion from x-expressions. We've been very happy with this approach, and using a DSL has given us concrete benefits over what we were doing before (even in Racket). If anyone is interested, I discussed how we incrementally moved toward a DSL in my RacketCon talk <https://youtu.be/pv0lLciMI24?t=5455> (more specifically this part <https://youtu.be/pv0lLciMI24?t=6016>), and both the generated documentation <https://docs.racket-lang.org/ricoeur-tei-guidelines/Formal_Specification.html> and some details about the DSL implementation <https://docs.racket-lang.org/ricoeur-tei-utils/Specification_Language.html> are online. On Mon, Feb 4, 2019 at 1:34 PM David Storrs <david.sto...@gmail.com> wrote: > as Neil pointed out, a good > candidate would be medical data that needs to be readable 100 years > from now. My question, however, was about how often those cases > actually come up in practice Our main reason for using XML is external standards, but we have found a benefit along these lines for incremental refinement. The standard we are are working against is enormous, and, as I said, we use a subset that we try to keep as small as possible while meeting our immediate needs. That means we end up iterating our project-specific requirements fairly rapidly, sometimes in intentionally backwards-incompatible ways. Having a layered approach to validation—broad, stable requirements validated with general XML tools plus project-specific requirements checked with Racket contracts, which we change more agilely—has helped as a sanity check and to give us some level of consistency across iterations. You could do this with other formats, too, and I think other formats are often better choices, but XML's story for validation seems more mature and more widely supported than, say, JSON Schema. On Sat, Feb 2, 2019 at 11:57 PM David Storrs <david.sto...@gmail.com> wrote: > The ability > to type data (e.g. specify that 'age' elements are measured in days, > or years, or etc) is a good feature, and I'll give XML that one. This is actually an annoyance of mine about XML. Many schemas indeed do specify semantic meaning for data in these ways, and W3C XML Schema Definitions <https://www.w3.org/TR/xmlschema11-1/>, for example, does try to address translating types into the application level. In practice, though, I don't think I've ever been able to take advantage of this: XML data comes in as strings, and, even if I know (and have validated) that some string will be an ISO 8601 date, I still have to deal with parsing it and often discarding whitespace myself. It's the same with JSON when you get to more complex types, but at least there are a few more atomic types than just strings. -Philip -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
