OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The one element schema language



 From: Joe English <jenglish@flightlab.com>

>[ Note: this is based on yesterday's draft -- Rick added some
>  features to the language while I wasn't looking :-)

The features I added were a postfix "." fullstop, to say the element is
empty,
and a postfix ";" group-break, to say that the  element cannot contain other
elements in the same group (the default is they can).  In the case of ";"
appearing in an [] group at the end, this is the same as defining them to
have data content only.
So a "." means stop, and a ";" means break, which is pretty natural.  (The
";" may need a different definition to fit in with implementations
better--it is just to pluck the low-hanging fruit.)

>Under TENTATIVE ASSUMPTION 1, a hook-schema actually induces
>a "strict weak order" (in the C++ STL sense) on NCNames.  (A
>strict weak order is stronger than a partial order but weaker
>than a total order; a relation '<<' on S is a strict weak order
>if there is a homomorphism from (S, <<) to (Z, <) where (Z, <)
>is a totally ordered set).
>However, TENTATIVE ASSUMPTION 1 does not hold in general since
>it's contrary to Rick's spec, which explicitly allows NCNames to
>appear more than once in a hook schema.

So what should I call it, if it is neither partial order nor strict weak
order?

>This suggests an efficient implementation
>(Rick -- does this look like what you had in mind?

Looks great to me.   One tricky thing that I am not sure about is that I
would allow the schema element inline in a document, anywhere before the
hook-end (i.e., it could
be first child, or second child if the first child was empty, etc) so that
the SAX implementation would be able to read validate the bits of the
document already gone by, and so we avoid using PIs (though, of course, a PI
would be fine for this since there is no element structure).

Do you think it would be better as a PI or an element like that?

> I suspect I'm missing
>something here, since your example hook schema for XHTML Basic would
>actually reject many documents that are DTD-valid with the above
>validation algorithm.  It does seem to work for the other examples
>you gave (PurchaseOrder, RSS, and Schematron) though.)

Probably that schema is wrong (what was the problem?)

Cheers
Rick Jelliffe