W3C home > Mailing lists > Public > public-microxml@w3.org > January 2013

RE: A really micro schema language

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
Phone: +1 812-482-5224
Cell:  +1 812-630-7622

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:12:12 UTC