fix leading digit bug

[AndreVirtimo]

XML element names must not start with a digit. This fix adds "n_" to the name.

[johnjaylward]

it should probably just throw an xmlformat exception of some kind instead of changing the element without notice.

[AndreVirtimo]

Why throw an exception, when the input is valid JSON and the desired output
is XML? At some point you have to make a trade off. Everybody who wants to
convert JSON to XML should know that a 1on1 matching is not possible.

[douglascrockford]

The choices are throwing or leaving it as is. Which shall it be?

[johnjaylward]

the reason to throw is that I don't want my data or keys modified without my knowledge. If the developer knows that a transition from JSON to XML is required, then choosing keys and data that fit in both models is the only proper way to go about it. Just having "magic" modify stuff is 100% wrong,

[stleary]

The other supporting classes handle toString() validation as follows:

Class	Validation
Cookie	no validation
CookieList	no validation
HTTP	throws exception on incomplete header
JSONML	throws exception on whitespace in tagnames and attributes
Property	no toString() method

So at least some of the classes do some validation. Agreed that arbitrarily changing the data is not the best solution. No objection to throwing a JSONException, but it seems to me there are lots of other invalid outputs that would also need to be checked. Not sure that XML conversion is worth the effort.

[johnjaylward]

I think the easiest way to handle XML validation would be to use an XML writer instead of string concatenation, but that would require a bit of re-write there. I don't personally use the XML outputs, so I can't say I'd put in any effort for it.

--edit
It would also likely add an external dependency that we probably wouldn't want. The javax.xml package would probably be the least invasive.

[stleary]

I am planning to use JSONML for one of my projects, so I guess I have an interest. We already have XML.noSpace(), currently only called from JSONML.toString(). It might be reasonable to call it from XML.toString(), and refactor it to include a check for leading digits, and possibly a few other simple checks that are compatible with both classes.

[AndreVirtimo]

I see the point. But I in my case I have no control over the input. My
system can only work with xml-data.

Another solution could be a configurable replacement-pattern, with a more
or less meaningfull defaultvalue. In this case the validation should use a
regex with detects more special cases (
http://www.w3.org/TR/REC-xml/#NT-NameChar). This could be made without a
high effort.

Andre Schlegel
Virtimo AG

M: +49 175 6785374
T: +49 30 555 744 033
F: +49 30 60 92 25 51
[email protected]
http://www.virtimo.de

Münzstraße 5
10178 Berlin

Sitz der Virtimo AG: Berlin
Vorstand: Christoph Fuchß, Dirk Breitkreuz
Vorsitzender des Aufsichtsrates: Prof. Dr. Stefan Stieglitz
Registereintrag: Amtsgericht Charlottenburg, HRB 131281 B
USt-IdNr.: DE274491859

2015-05-08 17:20 GMT+02:00 Sean Leary [email protected]:

I am planning to use JSONML for one of my projects, so I guess I have an
interest. We already have XML.noSpace(), currently only called from
JSONML.toString(). It might be reasonable to call it from XML.toString(),
and refactor it to include a check for leading digits, and possibly a few
other simple checks that are compatible with both classes.

—
Reply to this email directly or view it on GitHub
#123 (comment)
.

[johnjaylward]

If you have a standard input specification, you could pre-process JSON before doing the XML conversion to change invalid keys. I'm not sure how large your dataset is, but for small inputs it seems reasonable.

JSONObject jo = readMyInput();
// clean up invalid stuff for XML transition
if(jo.has("1key"){
    // you can inline these 2 lines as well
    Object val = jo.remove("1key");
    jo.put("n_1key",val);
    //  jo.put("n_1key",jo.remove("1key"));
}

// output to xml

This is really business rules for your application and not something that everyone would need or want. Putting this cleanup into a custom function in your application seems to be the most logical solution assuming you wanted to run with stock JSON Java implementation. If you don't mind running a modified version, I don't see a problem with your existing code change. I just don't think it fits with putting it in the core library. I do agree that some validation needs to happen, but modifying the keys even with a default/configurable value isn't a solution that should be in a shared library.

[mdaehnert]

Why don't simply split the XML.toString()-method into 2 separate API-methods? The first one will throw an Exception if some illegal node is found, the other will replace with given char.

So the user can choose it's apropriate handling.
Code of checking and throwing/replacing also can be used non-invasive.
@see my pull-request for regex-check.

API could look like:

public String convertWithValidation(JSONObject obj) throws JSONException
public String convertWithReplacingIllegalNodeChars(JSONObject obj, char replacement)

[stleary]

Not sure I understand; how would the app know which version to call? Let's continue this on the open pull request #138.