- From: David Lee <David.Lee@marklogic.com>
- Date: Wed, 16 Jan 2013 20:14:28 +0000
- To: Brian Kardell <bkardell@gmail.com>, John Cowan <cowan@mercury.ccil.org>
- CC: James Clark <jjc@jclark.com>, Michael Kay <mike@saxonica.com>, "public-microxml@w3.org" <public-microxml@w3.org>
- Message-ID: <6AD72D76C2D6F04D8BE471B70D4B991E044EB8@EXCHG10-BE02.marklogic.com>
Curious as to oppinions to the role of a MicroXML Schema language. To my understanding Schemas (can) serve multiple roles 1) Define a type system 2) Define constraints for validity So far the discussion on MicroXML Schema has focused on #2 ... Does #1 have benefit ? ----------------------------------------------------------------------------- David Lee Lead Engineer MarkLogic Corporation dlee@marklogic.com Phone: +1 812-482-5224 Cell: +1 812-630-7622 www.marklogic.com<http://www.marklogic.com/> From: Brian Kardell [mailto:bkardell@gmail.com] Sent: Wednesday, January 09, 2013 12:42 PM To: John Cowan Cc: James Clark; Michael Kay; public-microxml@w3.org Subject: Re: A really micro schema language On Wed, Jan 9, 2013 at 12:37 PM, John Cowan <cowan@mercury.ccil.org<mailto:cowan@mercury.ccil.org>> wrote: James Clark scripsit: > Though it pains me to say it, I suspect the most appropriate MicroXPath is > CSS3 selectors. The trouble there AFAICT is that selectors allow you to refer to element F contained in element E (with the path "E F"), but there is no way to talk about an element E which contains an F. In XPath terms, the only predicates are attribute-based predicates. Also the CSS3 design suffers from the second-system effect: it was just enhanced without being redesigned, and would be awkwardly big to just adopt. MicroXML demands something with more conceptual integrity, I think. -- John Cowan cowan@ccil.org<mailto:cowan@ccil.org> http://ccil.org/~cowan In the sciences, we are now uniquely privileged to sit side by side with the giants on whose shoulders we stand. --Gerald Holton Selectors level 4 has a "subject" selector (:has essentially, but even simpler) - though it seems no one is in a rush to implement it despite it being such a requested feature because of the performance implications. It is very likely that DOM's queryselectors will support a superset which are more powerful - the problem is essentially that pages are rendered as read so the process of applying them without making the page do crazy jumping jacks and spasms has to be really quick - the number of comparisons/rules that are evaluated on startup of an average page is insane and selectors like this leave no way to know without reading the entire tree in some cases whether a rule is true or not. -- Brian Kardell :: @briankardell :: hitchjs.com<http://hitchjs.com/>
Received on Wednesday, 16 January 2013 20:14:52 UTC