What about Schematron ? Uses xsd's but because it puts in xpath expressions and rules you can also do a lot more.
<schema xmlns="http://purl.oclc.org/dsdl/schematron";> <pattern> <title>Date rules</title> <rule context="Contract"> <assert test="ContractDate < current-date()">ContractDate should be in the past because future contracts are not allowed.</assert> </rule> </pattern></schema> Ben On Sun, Sep 29, 2013 at 7:58 AM, Jonathan S. Shapiro <[email protected]>wrote: > Thanks. I'm not looking for code templating. I'm looking for an input > format with standard validation and transformation tools. > > Unfortunately, I'm *also* looking to avoid admitting java into my build > chain (shudder). This seems to mean that I'm limited to xsltproc, which > supports Relax NG but not XML Schemas. My sense at one time was that Relax > NG had "lost" the political battle to be the preferred schema description > language. What's a bit weird is that xsltproc supports part II of XML > Schema (datatype specifications) but not part I (structure). > > It's frustrating to me that work on xsltproc proceeds to slowly. It hit a > plateau of being "good enough" and then Daniel got pulled into other things. > > > shap > > > On Sat, Sep 28, 2013 at 3:24 PM, david j <[email protected]> wrote: > >> I've at times had similar thoughts. >> >> I have used both XML/XSLT and Clearsilver (a similar but different >> text-transformation system) for code-templating. >> >> XML offers the benefit of schema validation and some amount of >> content-aware editing in good IDEs. Clearsilver has no data-schema >> concepts, but it has the advantage that it's template language is based on >> PHP-like <?cs ?> tags instead of XML, so your template fragments don't have >> to be well-formed XML, and don't have to use clunky things like > and >> < (a disaster for templating C code, I assure you) Clearsilver's dataset >> format (HDF) predates popular use of JSON, but the syntax is close. >> >> Things I like about using these methods, in order of priority: >> >> 1) I like to keep build dependencies simple, and so I much prefer using a >> text-templating engine which runs on a VM (JVM/CLR). This keeps my build >> simple and very cross-platform. I'd rather have one build dependency to >> solve (aka, have a JVM or CLR), rather than a bunch of custom-authored IDL >> translators, each written in their own languages, with their own platform >> issues like the google-protocol-buffer compiler or facebook thrift >> compiler. >> >> 2) text-templating is a nice way of doing compile-time meta-programming, >> and in some ways offers advantages over language-embedded techniques. For >> example, it's easy to see and reason about the templated output, and the >> same input spec can generate code in multiple languages. >> >> 3) I like the schema-validation, documentation, and editor-help of XML >> with XML-schema. (I have not yet tried to use a static XML-Schema/XSLT >> validator) However, the benefits of schema validation for my uses so far >> have been far LESS beneficial than the pain of being forced into >> well-formed XML. In fact, the reason I'm using XML/XSLT is because of #1, >> they are trivially available in CLR/JVM to simplify the build. I'd prefer >> to use Clearsilver, but it's written in C and I don't like wasting time on >> cross-platform build tools issues (I have enough of them in the projects!). >> >> Foward looking thoughts include... >> >> a) I have wondered if I could solve even more problems this way if I had >> a straightforward parse/lex to dataset converter (XML, Json, HDF, >> whatever). For example, to accept Google Protocol Buffer syntax, and use >> XSLT or Clearsilver to produce output code, rather than relying on their >> protocol buffer compiler. This would enable the trivial construction of >> code-transformation DSLs which are more convenient than XML or Json for >> data-input. >> >> b) I'm not clear on what the sweet-spot of these text-transformation >> techniques are, compared to general purpose programming. For example, most >> of my code templating use-cases basically have a dataset which drives >> structured macro-expansion, but not much logic or calculation. To me, the >> clarity and conciseness of doing this with text-templating tools is *very* >> apparent. However, I'm not sure what kinds of IDL transformations would >> have enough calculation to outweigh the benefits of concise >> text-templating. (note: while both XSLT and Clearsilver are turing >> complete, they are very inefficient at calculation WRT code-size) >> >> c) I have yet to see a great method for "packaging" up a specific >> application of text-templating as a component. That is, integrating it into >> IDEs and/or build-tools can still be a bit of a chore. Much better than >> integrating a bunch of custom IDL compilers though. >> >> Visual Studio T4 templating tries to do something here, with a method to >> compile T4 templates into library functions, but T4 is not a good fit for >> my use cases. It'ss designed to do one-to-one T4-to-C# code templating, >> wheras I need a shared piece of "templating software" which drives >> dataset-to-C# code templating. (If the meaning of this isn't clear, I'm >> happy to elaborate) >> >> >> >> _______________________________________________ >> bitc-dev mailing list >> [email protected] >> http://www.coyotos.org/mailman/listinfo/bitc-dev >> >> > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
