- From: David Lee <David.Lee@marklogic.com>
- Date: Tue, 14 Aug 2012 06:24:39 -0700
- To: Uche Ogbuji <uche@ogbuji.net>, Dave Pawson <dave.pawson@gmail.com>
- CC: MicroXML <public-microxml@w3.org>
Uche : ----- There really is nothing to respond to such assertions but "we shall see." And I think that's the last thing I'll be saying in response to questions such as "what's the point of MicroXML?" I'm turning my attention now strictly to its development. ------------- This is my biggest objection to the development of uXML as well as the biggest objection to at least a dozen people to whom I have discussed it (but have largely been silent, I take it on myself to be their voice ... for now). Without a clear definition of "What's the point" ... i.e. target audience, use cases, problems being solved etc., there is no objective basis for design decisions. It is literally the cart before the horse. How can you analyze the value of an implementation choice without having a clear definition of what it is you are trying to accomplish ? I suggest it is blatantly clear from the discussions that while many people think it is obvious "what is the point?" that no two people will give the same answer. I have heard wildly different answers from the chairs and co-chairs of the committee itself ... let alone the brave members willing to ask. Answering that question by ignoring it and skipping directly to development I suggest is a road to disaster. You will not get consensus because people will not have the same idea as to what it is you are trying to build so their design criteria will differ. Without consensus you might build something ... but what ? That is a path of a single developer which is a fun and efficient way of building things ... often wonderful things ... but if you want community feedback, help, criticism and support and want to build something that has a measurable goal you must answer seemingly irrelevant or unanswerable and stupid questions like "What is it?" "Who is the intended audience?" "What problems are attempting to be solved ?" "How can we measure if the problems were in fact solved ?" .... The alternative ... is to go build it, build the tools, write the documentation then come back and say "Here it is, take it if you want it" .... That can (and has) led to wonderful things but it is orthogonal to a community process. ----------------------------------------------------------------------------- David Lee Lead Engineer MarkLogic Corporation dlee@marklogic.com Phone: +1 650-287-2531 Cell: +1 812-630-7622 www.marklogic.com This e-mail and any accompanying attachments are confidential. The information is intended solely for the use of the individual to whom it is addressed. Any review, disclosure, copying, distribution, or use of this e-mail communication by others is strictly prohibited. If you are not the intended recipient, please notify us immediately by returning this message to the sender and delete all copies. Thank you for your cooperation.
Received on Tuesday, 14 August 2012 13:25:05 UTC