>What is the exact purpose of this module? Or asked differently, what do >we expect clients do with the parsed content?
some background about contentparser in this initial thread [1] my use cases are: 1. load content from JSON or JCR XML files into mock repositories in sling-mock (resourceresolver-mock, jcr-mock, oak) -> import to repository via Resource API (not JCR API) 2. load content from JSON or JCR XML files for mounting them in the fsresource provider -> hold data in a cheap in-memory-cache for developer machines mounting a couple of projects with fsresource 3. probably migrate the JSON content parsing part of jcr contenloader to this lib, it has the same parsing logic implemented currently 4. outside sling i've other projects which need this logic as well e.g. [2] as 1. and 2. are maintained in two branches we've currently 4-5 active projects in sling that need this component and more projects outside, and we do not want to duplicate the logic again and again. my first intention for the API was to have nearly no API, so i used nested maps for content representation. this created problems with the JCR specialty allowing node and property with same name, so this thread with the new proposal with a very thin layer above the nested maps. i do not want to make the API more complex. but we need some sort of interface to get the parsed content in a hierarchical form to process it further. one perhaps open question is if a stream-based API is better than an "in-memory" map-based API. for use cases like contentloader and mock-import stream-based is better, for fsresource map-based is easier. of course it's possible to create a map with a stream-based API, but then helper methods like "getChild(path)" is duplicated again. stefan [1] https://lists.apache.org/thread.html/8c7b540d266f975308681513f1896b45944cace4fc1eea2168cf345b@%3Cdev.sling.apache.org%3E [2] http://devops.wcm.io/conga/
