Re: A really micro schema language

I think the key to having a really small schema language is that it must 
extend gracefully to be capable of expressing complex constraints.

That could be as simple as adding a clause like

   person/@date[. castable as xs:date]

   car/@colour[. = ('red', 'green', 'blue')]

where the square brackets contain an assertion in the form of an 
arbitrary XPath expression.

If you had this, I think you could dispense with // outside the brackets:

   form[not(.//form)]

For such clauses to be useful to an editor, of course, it would have too 
look for common patterns in the XPath expression to recognize things 
such as enumerations; but that's not demanding too much, I think.

(Perhaps the square brackets look too much like XPath predicates and 
different syntax would work better, especially when the assertion itself 
contains predicates)

Michael Kay


On 18/12/2012 09:49, James Clark wrote:
> Here's an idea I was playing around with a while ago.  It relates to 
> the PossibleChildren property John mentioned.
>
> Imagine a really, really simple schema language that
>
> - uses a non-XML syntax;
>
> - allows a parser to do reasonable error recovery (and thus markup 
> minimization, if you ignore the errors);
>
> - allows editors to provide a useful-level of authoring assistance.
>
> I think the starting point would be being able to say which elements 
> are possible children of other elements.
>
> What might this look like? Here are some examples.
>
>   ul / li
>
> This is schema that says that a ul element can have any number of li 
> elements.
>
> A ul element may have any number of li child elements.
>
>   ul, ol / li
>
> This is equivalent to:
>
>   ul / li
>   ol / li
>
> The ul element and the ol element may each have any number of li child 
> elements.
>
>   p / b, i
>
> This is equivalent to:
>
>   p / b
>   p / i
>
> The p element may have any number of b child elements and any number 
> of i child elements.
>
>   p / .text
>
> The p element may (directly) contain text. An element that can 
> contain child elements is automatically allowed to contain whitespace 
> between
> those elements, so this really means that the p element may 
> contain non-whitespace text.
>
> An img element must have a src attribute whose value has the url datatype.
>
>   /html
>
> An html element may be the root element.
>
>   math / *
>
> A math element may have child elements with any name.
>
>  p !/ p
>
> A p element must not have a p child element.
>
>  br !/ *
>
> A br element must not have any child elements.
>
>  br !/ *, .text
>
> A br element must not have any child elements and must not have any 
> text content.
>
> I think you would need to handle attributes as well, which can be done 
> without too much complexity.
>
>   a @ href
>
> The a element may have an href attribute.
>
>   a @ href, type
>
> This is equivalent to:
>
>   a @ href
>   a @ type
>
> A next step might be to use // to say things about descendants.
>
>  form !// form
>
> A form element must not have any form descendant elements.
>
> Obviously, this is far from fully baked.
>
> James
>
>
>
>
>
>
>

Received on Tuesday, 18 December 2012 10:38:52 UTC