XSchema Spec Section 2.2, Draft 1

[Paul Prescod]

Simon St.Laurent wrote:
> 
> It's not quite clear to me either whether NOTATION is in or out, though it
> does have a place in the current outline.  If NOTATION is in, ID attributes
> should not be used for both types of declarations.

I say keep notation checking. They are harmless, sometimes useful, and do
not completely duplicate any other W3C spec. coming down the line.
 
> We need to define behavior for the verifier (my term for validator, since I
> don't want to get twisted in DTDs).  

Good!

> The verifier could check that all element
> names are unique, or it could accept the first or last element declaration
> made.  Allowing repeated declarations - which override would make it easier to
> combine XSchemas, but could also create a mess.  (Attributes? Content models?)
> Whatever we decide, the verifier is going to have some work to do.

If you adopt my model described today, you do not have this problem. Each
rule that applies to an element is checked. There could be a dozen, or
one. If an element has multiple content models, then its content must
conform to all of them. <ASIDE>It is well understood in regular language
theory how to combine multiple regular expressions into one...though the
created expression could in rare cases be quite large</ASIDE> 

The constraints that relate to attributes can also be checked easily. For
instance most elements will have an "open" list of attributes. So the
constraints would only be that the attributes that exist in the document
match the declarations in the XSchema when they exist:
<RULE>
    <ELEMENT NAME="FOO"><TARGET-ATTRIBUTE NAME="BAR"></ELEMENT>
    <ATTRTYPE>CDATA</ATTRTYPE>
</RULE>

Elements that have a "closed" list of attributes would have a declaration
that specifies that the list is closed:

<RULE>
    <TARGET-ELEMENT NAME="FOO"/>
    <AttrsMustBeDeclared/>
</RULE>

> I would like to be able to build XSchema applications on top of non-validating
> parsers - dealing with validation as well as XSchemas seems like a lot of
> redundant effort to me.  I don't think we gain that much from using ID.

I agree.

I don't want to push my XDocInfo/constraint model too hard, because I
can't help people to figure it out over the next few days. I think that it
is promising enough that if XSchema takes the more conserative (and
well-tested) route, I will pursue the XDocInfo stuff on my own.

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

Three things are most perilous: Connectors that corrode
Unproven algorithms, and self-modifying code
http://www.geezjan.org/humor/computers/threes.html

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)