To David(x2) >>> ". if you look at the sc:* functions you can parse to get to schema. And then using a few functions to build out the structure you need create a function that does the transformation for you. " >>>I did investigate this approach but it was not feasible in the context of the use cases where json:transform-xxx is targeted. >>> It may well be in individual cases, but doesn?t pan out so well for a general-purpose library
Not sure I agree, but would be interested in what area's you felt the sc:
functions are deficient. There are a few issues with some functions, but
given I am not a customer I cant make requests to fix.
>>>In general-- to do a schema based transformation -- you need schema for
*both sides*
>>>If you don?t care about deterministic transformations or bi-directional
transformations, you can make do with less.
In most cases you are trying to convert format not definition such as
XML->JSON or XML(Schema) -> CSV. In XML->JSON there can be general rules
and some assumption of lossiness, but since the ask is XML(Most Complex) ->
JSON(Simpler) this precision can be resolved by making some assumptions on
how to treat mixed or other types. Not a panacea, but dont let perfection
be the enemy of the good.
>>the 'sc:*' functions mentioned expose the results of schema validation,
not the schema itself.
>>That?s a subtle problem that makes them not as useful in this case as one
might think.
>>The sc:* functions operate on *instances* of XML data. Post schema
validation.
>>You can't use them to query a schema document in the sense desired.
>>They are a Reflection API into instances of validated documents,
expressed as schema attributes/axis on the node.
>>They are not a reflection API into the schema document itself.
I wouldnt recommend to anyone anything I didnt already figure out myself.
Your assumption is correct if you ask for a schema without knowledge of the
document its targeting, but considering you have a target document in
mind(which is always the case) this will return the initial schema:
sc:type($my-element-node-matching-schema) ! <x>{.}</x>/node()
>From here its knowing how to manipulate the sc:* functions to bend to your
will.
>>Even that has problems -- most JSON parsers use 64 bit doubles to
represent Number -- >>which means any integer > 52 bits get corrupted. ML
data types use 64 bit unsinged >>integers extensively -
Given that you have that issue I recommend using 2 32 bit values and using
the appropriate conversion on client. Since you have the XML schema you
already can account for that.
http://stackoverflow.com/questions/209869/what-is-the-accepted-way-to-send-64-bit-values-over-json
>>xs:date, dateTime, duration -- majority of xsd primates -- no standard
JSON representation.
No question, but its not impossible to create a json schema from XML Schema
assuming some loss of precision, the goal is to not naively assume a
panacea (no argument here), but use the knowledge of your XML schema to
make general rules about how to process. Using JSON Schema you can assume
its a string with the notion of a format
http://json-schema.org/latest/json-schema-validation.html#rfc.section.7.3
>>There is still a challenge -- even in theory.
>>Produce a single transform that is valid, lossless *and* universally
desirable.
Not sure that was his ask but dont disagree with you. Have you considered
"Middle-Out" transformation or the effect of MJT?
... dont answer this
>>The last part -- that?s the fun part. Figure how to determine what is
'desirable' -- universally.
>>Then implement it simply. Produce what is desired, not what is asked
for.
>>Make People Happy.
Not trying to solve universal problems, just try to steer one to a path of
happiness or frustration.
>>Very interested in how to achieve that better.
David, given you are an engineer for MarkLogic I realize you are obliged to
give the sanctioned answer from ML, but you need to consider that not
everyone needs the universal nor supported answer, but know what is
possible. I think you did a good job describing the pitfalls and
challenges, none that I have not faced already and griped about heavily
(not ML's problem just as you said not solved anywhere). There are
trade-offs and "good enough"s that satisfy the requirements. Impedance
mismatch is a problem everyone should understand for sure. But often there
are means by which one can solve 90% with 10% effort, that is the balance
we all strive for.
To the Steiner,
I have written this code somewhere and lost it during my latest laptop
migration. But I will share an example I have used today for a project
which should give you a sense of what sc:* can do for you and will rewrite
project as git repo at https://github.com/garyvidal/ml-libraries ... So
stay tuned.
In the example it simply enumerates your schema based on the sc:type of a
given document element and creates a search:options node you can pass into
search:search.
Here are some things I will share soon:
- XML Schema to JSON Document Conversion
- XML Schema to JSON Schema generation.
- XML Schema to Partial Update with customized ordering semantics.
Generates a builder function map that allows dependency injection of
recursive typeswitch.
- Any other reasonable requests.
Regards,
Gary Vidal
sc-component-extensions.xqy
Description: Binary data
_______________________________________________ General mailing list General@developer.marklogic.com Manage your subscription at: http://developer.marklogic.com/mailman/listinfo/general
