Been playing around with articy:draft for a week now and am really liking it.
I am wondering if something like this idea (a metadata driven XML export process) has ever been discussed internally, and if so, why it wasn't adopted. And if not, of course feel free to take my idea and run with it.
But I am mostly interested in hearing if this was investigated, and if so, why it wasn't chosen. Difficulty? Time to implement? Limited usefulness? Something else?As I understand the export process, today there are two fundamental ways to get the data into my engine:
- I will consume your XSD and write code to essentially wrangle that data into my own format. The classic Exporter -> Importer chain. Tried and true, and everybody understands it. Depending on how close the two schemas are, this could be a very simple XSL / XPath transform. Or it may need to be a very complex program.
- The other option would be to use articy:access and instead of using my own middleware api to get at my own custom formatted data, I would instead use yours. That is not an option at this point, although I do think it's a great option.
I would like to propose a third alternative: a visually programmable metadata-driven export pipeline. In other words, a way to tell Articy what it should be exporting, so that the output XML matches what is expected in the tool chain, and thus no glue is needed.
In such a system, you do not publish an XSD. You *consume* an XSD.
Instead, you provide a tool which allows developers to define the schema they expect. In other words, they provide an XSD of what they expect, and using your "mapping" GUI they visually build the glue which binds your internal DOM format to their expected XSD. For example:
- What may be a simple list of objects for you may need to grouped into hierarchies, or vice-versa.
- Elements in your DOM may be attributes in theirs, and vice versa
- Of course, naming will rarely match up
- Where they have data your system does not, defaults need to be specified
The toolchain now has one less (potentially) significant piece of custom code. The export process becomes data-driven, not code-driven. No piece of "glue" sits between your export and the import into the engine, massaging the data into the correct format. Instead, your export is essentially programmable via metadata, so that the XML it outputs is directly consumable by the engine.
Of course, this would scream for templatization, people sharing templates over the Internet for allowing proper expect directly into specific engines, and so forth. All good stuff to be sure.
Obviously this is a substantial piece of engineering for something that already has (at least) two other solutions. But I do think it would have merit, and I do think people would use it.
So the question stands, is it (or something like it) anything that was discussed?
Later,
Ryan
