tag:blogger.com,1999:blog-3944976411672994427.post6528634371451651800..comments2023-09-03T17:53:38.313+07:00Comments on James Clark's Random Thoughts: More on MicroXMLJames Clarkhttp://www.blogger.com/profile/04798042939786677843noreply@blogger.comBlogger42125tag:blogger.com,1999:blog-3944976411672994427.post-89841021609984778242011-03-20T22:12:28.037+07:002011-03-20T22:12:28.037+07:00James, how would MicroXML fit in with Efficient XM...James, how would MicroXML fit in with Efficient XML Interchange (EXI)?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-7910345585113113702011-01-31T12:51:06.003+07:002011-01-31T12:51:06.003+07:00I've put together a very preliminary MicroXML ...I've put together a <a href="http://www.ccil.org/~cowan/microxml.txt" rel="nofollow">very preliminary MicroXML draft specification</a>.John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-55218115441725901562011-01-22T03:00:33.449+07:002011-01-22T03:00:33.449+07:00I have released MicroLark 0.8, a parser/writer/tre...I have released <a href="http://recycledknowledge.blogspot.com/2011/01/microlark-parser.html" rel="nofollow">MicroLark 0.8</a>, a parser/writer/tree-model package for MicroXML written in Java. It implements MicroXML as specified in this post, with the addition of prefixed attribute elements (it allows, but does not require, declarations of those prefixes).John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-26054497949363571632011-01-14T23:37:56.655+07:002011-01-14T23:37:56.655+07:00My previous concern that prefixes require declarat...My previous concern that prefixes require declarations ("xmlns:foo") is answered I now see by the above MicroXML limit to just the special (according to the XML Namespaces spec) prefix "xml:" which the said spec says doesn't need a declaration. Maybe we need a list of all the possible xml: values and uses (or a subset of them?) and requirements for implementing them (like not rejected them when mixed with another vocabulary/model).Stephen D Greenhttps://www.blogger.com/profile/11733910745267236574noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-6196661449837020072011-01-14T16:06:00.097+07:002011-01-14T16:06:00.097+07:00John, David,
Yes but wasn't the beauty of allo...John, David,<br />Yes but wasn't the beauty of allowing the xmlns="foo" namespace attribute that it preserved compatibility with XML Namespaces. Allowing prefixes in attributes, worthy though it's purpose may be, seems to me to be very costly if it breaks compatibility.Stephen D Greenhttps://www.blogger.com/profile/11733910745267236574noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-67017957990674813682011-01-14T03:12:30.784+07:002011-01-14T03:12:30.784+07:00Steve, who saids you need to declare namespaces?! ...Steve, who saids you need to declare namespaces?! If something has a ns: prefix to its name - then assume it is processing instructions or other semantics, separate from the data content, otherwise ignore. Simple.DRRWhttps://www.blogger.com/profile/00601142988520298325noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-3621464346924938092011-01-14T02:12:21.179+07:002011-01-14T02:12:21.179+07:00QName introduces the logic that the prefix part MU...<i>QName introduces the logic that the prefix part MUST match a prefix in a namespace declaration, doesn't it?</i><br /><br />Yes for XML with Namespaces, no for plain XML, and whatever we like for MicroXML. My proposal is to allow "foo:" in attribute names, but <i>not</i> to require "xmlns:foo" attributes to match them. If such an attribute is present, great; your document is XML with Namespaces compatible. In any case, attribute names are still just strings in the data model, whether they contain ":" or not.John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-80336208157362265942011-01-13T22:26:38.136+07:002011-01-13T22:26:38.136+07:00The problem, I think, with namespaces for attribut...The problem, I think, with namespaces for attributes involving prefixes is that this introduces the concept of QName and I thought one requirement for MicroXML is that it allows the XML to be treated very much like just text. A QName introduces the logic that the prefix part MUST match a prefix in a namespace declaration, doesn't it? That seems to be too much for something intended to be so simple.Stephen D Greenhttps://www.blogger.com/profile/11733910745267236574noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-85706368540639382322011-01-12T03:50:10.801+07:002011-01-12T03:50:10.801+07:00Steve, ignoring foreign namespace attributes works...Steve, ignoring foreign namespace attributes works great! Typically injection of attributes is a great way to pass processing instructions and directives that are not part of the data content. We use this in CAM for example to inject error, warning and informational parsing results. So we'd expect any handler to simply strip these out after digesting and acting on them.DRRWhttps://www.blogger.com/profile/00601142988520298325noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-27705512647938644722011-01-10T18:25:19.038+07:002011-01-10T18:25:19.038+07:00Thinking about John's last comment, it seem to...Thinking about John's last comment, it seem to me that what makes namespaces useful to attributes is the potential use of foreign attributes. Attributes defined as part of a vocabulary do not need any additional namespace so they do not need a prefix (just a convention). Where something like 1 benefits from namespaces is when the attributes and maybe attribute values are from a foreign namespace, of course. Maybe would welcome, I think, a convention which says that such attributes need not be explicitly allowed by the vocabulary/namespace of the elements to be allowed in a MicroXML instance; the convention might be that they can just be ignored if their foreign namespace is not recognised in relation to the instance's namespace: But is that safe?Stephen D Greenhttps://www.blogger.com/profile/11733910745267236574noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-92202358734972050942011-01-08T14:08:49.867+07:002011-01-08T14:08:49.867+07:00I found an interesting IBM DeveloperWorks article ...I found an interesting IBM DeveloperWorks article by Parand Darugar called <a href="http://www.ibm.com/developerworks/library/x-abolns.html#betterexamples" rel="nofollow">"Abolish XML namespaces?"</a> Most anti-namespace screeds are just whinges, but this one isn't.<br /><br />I've linked to the section about the two use cases where he considers namespaces actually worthwhile. The first is in identifying a document type, which is what MicroXML @xmlns is for (although it can be used at the top of a subtree as well). The second is namespaced attribute names, and I'll quote it selectively here:<br /><br />Namespaces have a compelling use in providing unique identifiers for type information. You may have seen XML fragments such as: [...]<br /><br /><cost xsi:type="xsd:float">29.95</cost><br /><br />This conveys that cost has a type, and by type I mean type as defined by XSI, and that the type is float as defined by XSD. The key point here is that you are indeed looking for unique, non-context-related identifiers for each type. You are not combining your document with the XSD or the SOAP encoding document; you are simply referring to particular elements within each specification from your document. The specification need not even be in XML — you are referring to a flat structure, simply a list of types. If you believed that the type structure was hierarchical, you would need to fully qualify the path for the type, with something like:<br /><br /><cost xsi:type="xsd:/types/simple/float">29.95</cost><br /><br />[...]<br /><br />Perhaps this still isn't a reasonable use case for XML namespaces, but you have glimpsed a certain amount of usefulness. The lesson can be generalized as follows: <i>A method for associating the attributes of elements with external reference points might have value</i> [italics in original]. The element itself does not need a namespace, but its attributes might.John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-46776023307975009832011-01-02T09:57:55.010+07:002011-01-02T09:57:55.010+07:00On reflection, I think MicroXML should allow prefi...On reflection, I think MicroXML should allow prefixed attributes. It's cleaner to have "json:type" than "json-type" in an attribute architecture, because you can have a "xmlns:json" attribute in the MicroXML to carry namespace information for XML processors without special hackery. MicroXML processors just see both "json:type" and "xmlns:json" as ordinary attributes with no magic properties, the same as "xmlns", and leave it up to the application to process them specially if at all.John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-21428743518076055982011-01-02T09:53:14.154+07:002011-01-02T09:53:14.154+07:00Stephen (not D. Green): The obvious answer to the ...Stephen (not D. Green): The obvious answer to the attribute-type issue seems to me to be: Don't put data that needs to be JSON-visible into MicroXML attributes, or if you do, make sure it's string data only.<br /><br />I've just posted my current thoughts on <a href="http://recycledknowledge.blogspot.com/2011/01/microxml-and-json.html" rel="nofollow">MicroXML and JSON</a>.John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-6321612545110986192010-12-31T03:38:06.618+07:002010-12-31T03:38:06.618+07:00I cannot agree with the first paragraph. XML is in...I cannot agree with the first paragraph. XML is indeed a good, simple, extensible format for documents. It has the enormous advantage of having large amounts of software tool infrastructure already in place. It's not perfect for all possible uses, but nothing is.<br /><br />Kurt, MicroXML currently appears to be designed for people who want to build new parsers and software infrastructure, not for people who are creating, sharing, and reading documents. See for instance the difference in perspectives in the discussion of processing instructions in these comments. I agree that this does not seem like a compelling design rationale.<br /><br />In the MusicXML world, for instance, UTF-16 encoding and processing instructions are absolutely necessary features. Who cares if these features may complicate life a little bit for parser implementers? The number of parser implementers is totally dwarfed by the number of people reading, writing, and sharing XML documents.Michaelhttp://michaelgood.infonoreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-5150299531286241222010-12-30T23:46:27.527+07:002010-12-30T23:46:27.527+07:00Stephen, now you're talking! Yes - with CAM te...Stephen, now you're talking! Yes - with CAM templates - we're using xslt to write XSD for developers. This is a key feature for NIEM. The raw XSD for NIEM cause most developer tooling to crash - too much recursion - too much complexity. By writing the equivalent from CAM templates in simple XSD syntax - it avoids those issues - and logically the CAM and XSD are equivalent. <br /><br />So back to where you are at - generating XSD schema for MicroXML from a CAM template using xslt can work nicely - and results in dramatic simpler tasking for developers - because they do not have to be XSD syntax experts.<br /><br />Sine CAM is essentially WYSIWYG XML structurally - the MicroXML instance can plug straight in there - and the XSD be generated automatically. Even seems like cheating at times!DRRWhttps://www.blogger.com/profile/00601142988520298325noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-60658925086506609952010-12-30T23:25:42.088+07:002010-12-30T23:25:42.088+07:00For those who tend to use XSD (W3C XML Schema) wit...For those who tend to use XSD (W3C XML Schema) with XML and would like to use a very simplified version with MicroXML too, I've produced a cut-down <a href="http://lists.xml.org/archives/xml-dev/201012/msg00814.html" rel="nofollow">MicroXSD 'schema of schemas'</a>. It constrains XSD schemas for MicroXML to just 'local' elements and attributes (to avoid having to include more than one namespace and to avoid namespace prefixes). Within those constraints, the semantics would be the same as standard XSD. I've used the schema of schemas to generate random MicroXSD schemas using my favorite XML editor and subsequently used these random schemas to generate MicroXML-esque instances without any problems. It all makes MicroXML and a MicroXML stack including profiles for schema validation look quite feasible. 'Local' element and attribute definitions in an XSD schema have the advantage of making the schema look similar to the instances they constrain, I think (a bit like CAM and Examplotron).Stephen D Greenhttps://www.blogger.com/profile/11733910745267236574noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-72864552892217783752010-12-30T23:23:35.387+07:002010-12-30T23:23:35.387+07:00Stephen, lets not tie ourselves to XML Schema and ...Stephen, lets not tie ourselves to XML Schema and XSD! If you remove namespaces from the instances completely and use a CAM template as the (optional) way to add semantic context everyone wins! Then if you need to unravel what amounts to the dictionary side of XML - you reference the CAM template and it tells you contextually the semantics of the item you are interested in using XPath referencing and rules.<br /><br />This decoupling is a no brainer in my opinion - and especially as CAM templates let you automatically generate domain dictionary catalogues of components, OWL and HTML5 forms directly - using XSLT transforms - that you cannot do from the XSD equivalent.DRRWhttps://www.blogger.com/profile/00601142988520298325noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-61440112255909733192010-12-30T23:16:17.576+07:002010-12-30T23:16:17.576+07:00James, continuing the thought of MicroXML and OASI...James, continuing the thought of MicroXML and OASIS CAM - have speed read through the comments - one thing I have long found troubling is the "let's cram everything into the instance" mentality that rapidly becomes angle bracket coplexity. By separating semantics into a template you can dramatically reduce what is being transferred on-the-wire to the bare content essentials and let the template then provide heavy lifting on parsing and interpretation nuances and even repetitive content structures and detail.<br /><br />Someone mentioned audience for all this - I've been working with the NIEM community with CAM - targetting making everything dramatically simpler to do compared to XML Schema. When you give developers simpler more intuitive and robust ways to implement XML-based information exchanges - everyone wins.<br /><br />Also simpler should not mean less capable. The trick here is to deliver simple yet strong functional capability that matches 95% of business information needs; more than an 80:20 approach - but less than 100% of all possible needs; its that striving to cover off the last 5% that adds 200% of the complexity. It's OK to say - in MicroXML we are just not going to worry about certain aspects of markup complexity - and catalogue those items as "not supported" so people understand the design limitations selected.<br /><br />Thanks, DWDRRWhttps://www.blogger.com/profile/00601142988520298325noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-7287350847381468402010-12-30T22:50:56.624+07:002010-12-30T22:50:56.624+07:00James, I'd like to see also how we can tie the...James, I'd like to see also how we can tie the OASIS CAM template work into this as well.<br /><br />MicroXML and CAM seems like a very strong match...<br /><br />We're getting ready to do CAM v2.0 in 2011 - so adding MicroXML support would be a natural.<br /><br />Thanks, DWDRRWhttps://www.blogger.com/profile/00601142988520298325noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-62171225608231586802010-12-29T17:03:05.982+07:002010-12-29T17:03:05.982+07:00John Cowan:
I think a key feature of JSON is that ...John Cowan:<br />I think a key feature of JSON is that JSON data contains its own metadata to define/declare its datatypes (without the need for a schema). If MicroXML could match this then there would need to be a way to add corresponding datatype-related metadata to the XML, wouldn't there? If all of the JSON data is mapped to MicroXML <strong>elements</strong> then maybe that can be done using attributes to contain the type-related metadata. Could the MicroXML (mapped from some JSON) contain metadata about the type of an element's text content (without the use of a schema)? Might it need reserved attributes, etc?<br />But how would the MicroXML instance contain metadata about the type of an <strong>attribute's</strong> value (without a schema)?Unknownhttps://www.blogger.com/profile/08565392939038570678noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-30638014954270144332010-12-28T08:51:42.666+07:002010-12-28T08:51:42.666+07:00Stephen D. Green: If MicroXML couldn't do more...Stephen D. Green: If MicroXML couldn't do more than JSON, there wouldn't be much point in having it. My idea is not to be able to map every MicroXML document to a unique JSON document, but rather:<br /><br />1) to be able to map every JSON document to a unique MicroXML document and then recover the original JSON;<br /><br />2) to be able to write MicroXML documents in such a way that they can be "downgraded" to JSON when needed, using the json-type attribute.<br /><br />The so-called Java reference implementation of JSON provides such a mapping to XML, but the resulting XML isn't even guaranteed to be well-formed.John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-16698652058257416572010-12-27T03:00:44.052+07:002010-12-27T03:00:44.052+07:00If you wanted to write a simple schema (XSD) using...If you wanted to write a simple schema (XSD) using MicroXML (you might such a schema a MicroXSD schema), it seems to me that limiting MicroXML's namespace capabilities to just the xmlns attribute would mean you cannot include globals if there is no way to prefix the names of such elements, groups, attributes, etc in the XSD reference attribute. I guess in many cases it would be the simplest answer just to limit MicroXSD schemas to local elements, attributes and groups so maybe this is not enough of an issue to warrant the added pain of including namespace prefixes in MicroXML. It might be worth investigating and noting what are the main knock-on limitations this limitation in MicroXML places on any implementations of W3C XML Schema, etc.Stephen D Greenhttps://www.blogger.com/profile/11733910745267236574noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-11110763519127629392010-12-27T02:28:51.971+07:002010-12-27T02:28:51.971+07:00If the feature of MicroXML being able to match or ...If the feature of MicroXML being able to match or map to JSON is achieved wouldn't this mean providing a way to type not only an element's text content but also an attribute's value without the need for a schema? JSON types are strings, numbers, booleans, object, arrays, and null, including variations of the array type. Maybe a reserved type attribute can be used (profiled perhaps) to declare the type of an element's text content within the instance but how would the same be done for an attribute's value (within the MicroXML instance)?Stephen D Greenhttps://www.blogger.com/profile/11733910745267236574noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-18763945395181541032010-12-24T06:16:03.425+07:002010-12-24T06:16:03.425+07:00There's discussion of a MicroXSD on xml-dev. ...There's discussion of a MicroXSD on xml-dev. Of course, full XSD and RNG will work fine with MicroXML, but I thought I would put together a <a href="" rel="nofollow">MicroRNG</a> as well, as something small enough to be readily packaged with a MicroXML parser. It does simple DTD-style structural validation and not much more, but that's most of what you need at the parser level: the rest can be performed by the application.John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.comtag:blogger.com,1999:blog-3944976411672994427.post-25394948353268200162010-12-24T04:14:56.371+07:002010-12-24T04:14:56.371+07:00David Lee: It's definitely too awkward to try ...David Lee: It's definitely too awkward to try to round-trip MicroXML through JSON, but it's quite reasonable to be able to round-trip JSON through MicroXML in a standard way, defined up front. I think there are three plausible approaches:<br /><br />1) Define a standard set of elements that represent JSON objects, arrays, numbers, booleans, and null. That's the simplest thing that could possibly work, and I incline to it.<br /><br />2) Define a standard "json-type" attribute that you can add to arbitrary MicroXML elements to say what their JSON type is. Unmarked elements are strings. Some documents won't be convertible because they break JSON rules (a string in the root, e.g.)<br /><br />3) Recognize both possibilities simultaneously.John Cowanhttps://www.blogger.com/profile/11452247999156925669noreply@blogger.com