tag:blogger.com,1999:blog-11807812.post3354733168983562194..comments2023-05-29T08:58:13.381-04:00Comments on Recycled Knowledge: MicroXML and JSONJohn Cowanhttp://www.blogger.com/profile/11452247999156925669noreply@blogger.comBlogger10125tag:blogger.com,1999:blog-11807812.post-43529062619948266762011-01-05T14:35:39.207-05:002011-01-05T14:35:39.207-05:00Apologies, getting forgetful there.
I guess it ha...Apologies, getting forgetful there.<br /><br />I guess it has to be an attribute with a codelist of types then. Maybe reserved attributes could be specified in the MicroXML profile: xmlns, xmltype (with some codelist specified like xmltype="json:object|json:array|json:sequence|json:number..." perhaps including other types too like xsd:normalizedString). These attributes would be sprinkled in with a custom vocabulary but there is a downside of the attribute not being recognised in that vocabulary. An alternative would be type-declaring values added as reserved comments to the elements which would then avoid making the XML invalid. , or , etc. <br />Besides this there could be defaulting rules like every <br /> * element with untyped text content is assumed to be type 'string';<br /> * every element with mixed content with untyped text content is assumed to be a combination of type json:object and a reserved named JSON 'string' item (perhaps named 'xmlstring') <br /> * every attribute with untyped content is assumed to be type 'string'.Stephen D Greenhttps://www.blogger.com/profile/11733910745267236574noreply@blogger.comtag:blogger.com,1999:blog-11807812.post-67934776842907405882011-01-05T11:54:28.560-05:002011-01-05T11:54:28.560-05:00Attributes without values are an SGML/HTML thing (...Attributes without values are an SGML/HTML thing (really, the attribute name is the same as the attribute value), but not part of XML. I really don't want a MicroXML that isn't a subset of XML.John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.comtag:blogger.com,1999:blog-11807812.post-29675600129590024702011-01-05T11:49:40.415-05:002011-01-05T11:49:40.415-05:00How about a set of special attributes (which do no...<br><br /> How about a set of special attributes (which do not have values) with reserved <br /> names (e.g. starting with 'xml', if that were sanctionable) which when added to <br /> an element, declare for it a type (which maps to a JSON type):<br /> <br><br /> <br><br /> object: <n xmljto>v</n><br /> <br><br /> array: <n xmljta>"v1",'v2 v3'</b><br /> <br><br /> sequence: <n xmljtq>"v1",'v2 v3'</b><br /> <br><br /> string: <n xmljts>v</n><br /> <br><br /> number: <n xmljtn>v</n><br /> <br><br /> boolean: <n xmljtb>v</n><br /> <br><br /> null: <n xmljtl/> <n xmljtl></n><br /> <br><br /> <br><br /> I think this would go some way to solving both of your goals, wouldn't it, but <br /> without requiring a special vocabulary - and that way the XML can have any <br /> vocabulary, except that attributes pose a problem.<br /> <br><br /> For attributes there could be a convention like starting the value of the <br /> attribute with the reserved name followed by some special character (say a <br /> colon):<br /> <br><br /> <br><br /> object: <a n="xmljto:v"/><br /> <br><br /> array: <a n="xmljta:'v1','v2 v3'"/><br /> <br><br /> sequence: <a n="xmljtq:'v1','v2 v3'"/><br /> <br><br /> string: <a n="xmljts:v"/><br /> <br><br /> number: <a n="xmljtn:v"/><br /> <br><br /> boolean: <a n="xmljtb:v"/><br /> <br><br /> null: <a n="xmljtl:"/> <br /> <br><br /> <br><br /> or something like that.Stephen D Greenhttps://www.blogger.com/profile/11733910745267236574noreply@blogger.comtag:blogger.com,1999:blog-11807812.post-28529662263935604832011-01-05T04:21:28.977-05:002011-01-05T04:21:28.977-05:00MicroXML without attributes (in either your (a) or...MicroXML without attributes (in either your (a) or (b) style) would have somewhat less expressive power than JSON, because unlike JSON it would not be able to express types easily, so I see no point in having it. Converting MicroXML to JSON would inherently be a down-level conversion. I can't say I see any need for MicroJSON either: JSON is already small enough.<br /><br />I thought of xsi:type rather than json-type, but MicroXML currently doesn't allow prefixed attributes (I think it should, with or without namespace declarations). What's more, xsi:nil="true" would be the natural mapping of JSON null, but now we have two different attributes for types.John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.comtag:blogger.com,1999:blog-11807812.post-44956983054510585642011-01-04T04:02:18.900-05:002011-01-04T04:02:18.900-05:00One more comment: If there is a subset of MicroXML...One more comment: If there is a subset of MicroXML (whatever you call it but MicroXML without attributes except certain special ones) which can be mapped (with help from those special attributes) to JSON, is there also a subset or potential profile to identify (and name?) in JSON which best supports a roundtrip mapping? If the former is dubbed something like NanoXML, maybe the latter could be dubbed NanoJSON and the profiles of NanoXML and NanoJSON include the essential details for mapping them (including the special attribute(s)).Stephen D Greenhttps://www.blogger.com/profile/11733910745267236574noreply@blogger.comtag:blogger.com,1999:blog-11807812.post-37439941402197985862011-01-04T03:54:46.989-05:002011-01-04T03:54:46.989-05:00It interests me that one of your conclusions is to...It interests me that one of your conclusions is to discard MicroXML attributes apart from a special 'json-type' attribute. <br />Firstly this suggests that there would be value if either a) there were yet a further subset of MicroXML which excluded attributes arat from certain special attributes or b) that maybe MicroXML itself should exclude attributes apart from certain special attributes (one might continue to be 'xmlns'). Your suggestion seems to favour, rather than a modified MicroXML, a new vocabulary but I wonder if a new profile (NanoXML?) or adjustment to the MicroXML profile would better meet the need of being able to map to and from JSON.<br />Secondly there is the matter of those special attributes of which 'json-type' might be one. Should the 'xmlns' attribute be another? How best could a new special attribute like 'json-type' be included. I guess if you opt for a vocabulary over MicroXML then it would just be an attribute in the vocabulary but if the profile itself (Micro or NanoXML) is preferred then you might want it to include some useful new reserved attributes if it could get sanction at that level. Maybe something like 'xsi:type' is in order but perhaps profiled for MicroXML or NanoXML to avoid the use of the prefix - perhaps like the reserved 'xml-' in 'xmlns' (say 'xmljt' as a shortened 'xmljsontype'). Or do I misunderstand?Stephen D Greenhttps://www.blogger.com/profile/11733910745267236574noreply@blogger.comtag:blogger.com,1999:blog-11807812.post-91569686367050675492011-01-02T11:18:19.701-05:002011-01-02T11:18:19.701-05:00Keith left a further comment, but Blogger seems to...Keith left a further comment, but Blogger seems to have dropped it on the floor, luckily after it sent me an email copy. It read:<br /><br />"Ah, that's clearer alright! I don't know if you remember it you seem to be creating a subset of <a href="http://web.archive.org/web/20080416061705/http://www.openwddx.org/downloads/dtd/wddx_dtd_10.txt" rel="nofollow">WDDX</a>, which was an attempt half an age back to create something JSON-like, before JSON existed, in XML."<br /><br />I had never heard of <a href="http://www.infoloom.com/gcaconfs/WEB/chicago98/simeonov.HTM" rel="nofollow">WDDX</a> (different link) before, but it is scary close to what I'm describing, with the addition of a date-time (ISO 8601) simple type and a "recordset" aggregate type, in JSON terms an array of objects constrained to hold simple types only. If JSON had been designed from scratch without reference to JavaScript syntax, I'd guess it would have had date-time literals as well.John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.comtag:blogger.com,1999:blog-11807812.post-508082096924724132011-01-02T07:46:35.135-05:002011-01-02T07:46:35.135-05:00Ah, that's clearer alright! I don't know i...Ah, that's clearer alright! I don't know if you remember it you seem to be creating a subset of <a href="http://web.archive.org/web/20080416061705/http://www.openwddx.org/downloads/dtd/wddx_dtd_10.txt" rel="nofollow">WDDX</a>, which was an attempt half an age back to create something JSON-like, before JSON existed, in XML.Keith Gaughanhttps://www.blogger.com/profile/11467525080865173891noreply@blogger.comtag:blogger.com,1999:blog-11807812.post-54547701863205080462011-01-02T03:47:48.532-05:002011-01-02T03:47:48.532-05:00Ah. Yes, you are. I meant that we can't repr...Ah. Yes, you are. I meant that we can't represent the key-value pairs as attributes; that is, using the attribute name for the key and the attribute value for the value.<br /><br />I've clarified the text.John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.comtag:blogger.com,1999:blog-11807812.post-69523988669262200712011-01-02T02:18:02.536-05:002011-01-02T02:18:02.536-05:00"Next we must choose how to represent the key..."Next we must choose how to represent the key-value pairs within an object. They can't be represented as attributes, because the JSON RFC only says that keys SHOULD be unique, not that they MUST be unique."<br /><br />This, at least at first glance, reads a bit like a non-sequitur: how does representing a key as an attribute force keys to be unique? This markup fragment seems perfectly acceptable to me:<br /><br /><dict><br /> <string key="foo">bar</string><br /> <int key="foo">42</int><br /> <list key="baz"><br /> <string>fred</string><br /> <string>barney</string><br /> </list><br /></dict><br /><br />Am I misunderstanding you?Keith Gaughanhttps://www.blogger.com/profile/11467525080865173891noreply@blogger.com