ext:value property power are not same for json and xml

[zeldigas]

Here is a description of value property in spec:

The value property is OPTIONAL. The content is undetermined; its meaning and use SHOULD be explained by the document found by de-referencing the href property.

The problem is that in xml it's a node attribute, but in json it's just a object's property. As spec does not apply any constraints, saying the value is undetermined, in JSON I can use an object of any complexity I wan't, when for xml I can use only string of text.
I think that representations should be equal, and either restrict json version to string value of undefined content or allow xml version to insert any content in ext node along with (or instead) the atribute in ext node itself

[mamund]

well, good point. i'd like to say that the content MUST be a string
(CDATA).

does that make sense?

​

[zeldigas]

If we do not want "invest" in extensions, then yes, it should be as lean as possible.
for this i think spec should be smth like

The value property is OPTIONAL. The content should be a string; its meaning and use SHOULD be explained by the document found by de-referencing the href property.

In the opposite i think it would be a good idea for value to be a json/xml any content and the spec text:

The value property is OPTIONAL. The content is undetermined; its meaning and use SHOULD be explained by the document found by de-referencing the href property. For complex content xml version of document should insert content inside ext tag, instead of using "value" attribute.

[mamund]

I'd like to go w/ the second option if we can work it out safely. Mark and
I went around on this a few times and I just "gave up" and went for option
no. 1.

if we go w/ your no. 2, I think we need a way (within the tag/property)
to clearly identify what's coming in order to allow parsers to a) recognize
it or b) ignore it.

.....

or

{"ext" : {"name" : "reserved-words", "value" : object}}

​

[zeldigas]

Json value is ok, any valid json parser should handle it.
As for xml I think we can introduce rule:

tag content as a value always takes precedence over attribute "value". If ext tag has some content, either text or inner tags, parser MUST use it instead of attribute "value" content.

with this rule we provide enough information do handle ext data