>>>[DAL] I am not saying they are 'deficient' , I am saying that because
they require an *already created* document to query,
they are not generally useful as a means of determining how to
construct that document in the first place.
[GV] Not necessarily, transformation is a bit different than
transliteration. I think he was suggesting that XML->JSON is a
transliteration vs trying to match a different schema. In terms of already
created documents, as a "Framework" engineer, not a developer, I make no
assumptions about what data is represented by a schema or an xml document.
The presumption is that if you want a framework based approach vs a
hand-coded integration you live with trade-offs and using sc:* allows you
to reflect the type of document you have passed and then allow them to make
general configuration changes to augment the library using High Order
Functions, Dependency Injection or Pointcuts for refinement. The biggest
problem with XQuery development is people embed their transformations and
understanding into their code, so everytime the data model changes their
code has to change to reflect it. In my opinion this is worse than some
rigidity.
The schema is the construction template and the validation to prove it. As
noted, I have code that does partial updates (PATCH) against a set of zones
within the XML which must be defined according to multiple schema Types and
versions. The generic pattern allows me to create configuration driven
update processing without committing to a bunch of hardcoded dependencies
like recursive typeswitches or nested if statements. I have had to think
very hard how to achieve this given all the permutations of XML schema and
its target representations. Again there are cases I have not touched, but a
framework can abstract that out so it becomes a bug vs quitting because you
dont feel you are getting exactly what you want.
>>>[DAL] I'll up the ante one further. If you already have the source and
target document 'in mind' you don?t even need the sc:* functions.
[GV] - Because like reflection you may know whats in the document, but do
you know what should be in the document. The schema tells you this, your
developer will not. So consider any framework that had to be recoded for
every client because the XML and Schema were different. Writing "Schema
Aware" code is harder than writing a bunch of hand-coded xquery modules and
while I have to explain to the PM's who dont understand when I make a
change its system wide and affects more than their seemingly tiny ask.
>>>[DAL] problem only arises in the first place
when the target system cannot directly represent 64 bit integers as
'Numbers' -- That is only problematic if you need to do numeric operations
on them.
Otherwise its much easier to 'pass along' a string value, display it, even
do inequality operations then a structured value. It is also more compact,
more readable and more efficient.
[GV] So everyone is so happy to use a deficient transport format that
cannot handle anything aside from String,Number and Integer. So being a
purist is non-sensical if you ever consider JSON/Javascript a real
standard/language. Again readability vs correctness debate. But using your
XML schema you can pass this as JSON Schema to your client libraries and
will interpret them according to schema vs some developer reading the JSON
without any knowledge of its nuances. Again have built this feature and
happy to share once I can recreate from my head again.
>>>[DAL] To date, I have not yet run into a customer case that had an XML
schema for a JSON document they wanted to transform. So my 'gut feeling'
would be its more useful to write the json schema directly.
[GV] The truth is most customers using MarkLogic have legacy XML that they
are trying to modernize for client consumption. I have rarely had the
opportunity to build from scratch a data application using MarkLogic with
pure JSON. For that work I just go with JSON Schema and javascript
directly. Yet, I have many clients who are stuck with a ton of legacy xml
content, but have downstream clients who require JSON and other variant
formats (AVRO, Semantic Triples, etc). They dont have the luxury to
maintain multiple copies and disjoint schema definitions to satisfy
everyone's requirements. By building these abstractions out (even my own
Schema DSL in XQuerrail) I can with some degree of confidence and fact,
know my code works for all the cases I have encountered. And when it
doesn't or cant, I can do dependency injection or write custom code to
counter that.
>>> [DAL:] Not true, my answers are my own
Sure sorry was being snarky and welcome a healthy debate. But my
experiences are different and should assume we are all trying to educate.
Sometimes I operate on the fringes of the platform that are not understood
or apparent to most people. My thoughts are very abstract because I refuse
to write code that is brittle and dependent on any data model or schema, if
I am going to publish it for others to use, I need to consider what
trade-offs can be made when and where, so I can leave enough string to pull
when someone requires it to do so. And because I am lazy as hell, but care
about performance when doing large scale processing I find machine
generated code more efficient than hand-coded XQuery, because all the
optimizations can be generalized once and then re-applied over and over
again.
It is through code and examples we educate, with a splash of healthy
debate and humor. So hopefully soon I can write the article that explains
this in detail with examples I mentioned before. The hardest part of
writing code is not the code itself but the documentation and tests
required to have others understand.
_______________________________________________
General mailing list
[email protected]
Manage your subscription at:
http://developer.marklogic.com/mailman/listinfo/general
