Subject: RE: Craeted proposal: PaceProvideSchema

From: "David Orchard" <[email-masked]>
Date: Mon, 12 Jul 2004 10:19:04 -0700

I think that in almost all cases, the schema expresses a subset of the prose constraints.  However, machines have a tough time reading prose.  

There are 3 different things to think about when working on schemas that have been muddled together here:
1. Sorting out the ambiguities between prose and schema
2. Dealing with the constraints of the schema lanaguage
3. The meaning of normative versus non-normative.

1. Ambiguities.

I agree that there will be a period of time of sorting out differences and ambiguities.  But I've typically found that skipping that step is robbing peter to pay paul, that is the problems are just defered to the community forcing some kind of "interop" organization to figure out all the niggly bits when interop doesn't just happen.  

Would the "long period of sorting out ambiguities" be skipped in producing a non-normative schema compared to a normative schema?  It seems to me like people are thinking that "non-normative" means less work, ie lower quality.  

I think either sort out the ambiguities, or don't do the work at all.

2. Schema language constraints
Where I think this gets tricky is that different schema languages express different constraints and some constraints are impossible to express in certain schema languages.  For example: W3C Schema does not allow optional elements before a wildcard extensibilility in the optional elements ns (the determinism constraint).   If Atom wants to allow same ns extensibility after optional elements, it either can't write the XML Schema or it has to do some extra work to get around determinism.  The work is basically wrapping the extension with a known marker or element.  That also means that all the non w3c Schema languages would have to do the same work.  RelaxNG doesn't have this problem btw.  Should relaxNG schema have to do this work?

I think this is the biggest problem, that of the schema language constraints "leaking" back into the prose.  And how far does this go?  The probably knee-jerk response is "no leaky abstractions!", but that means that it might be 100% impossible to write a schema in a given language.  

3. Meaning of *-normative schema

I'm not quite sure that I understand the purpose of having an "informative" schema compared to a normative schema.  If the non-normative is the same quality as the normative, I don't get why it would be non-normative instead of normative.  

Sometimes people make schemas non-normative because they haven't done as much work as they think they need to, which I addressed in #1.  Other times, the schemas are non-normative because they use a schema language (maybe a pseudo-schema language even) that isn't widely deployed.  

I think the decision about *-normative should happen after the group decides whether the ambiguities between schema and prose will be resolved, and whether the schema language(s) will leak into the prose.  

Cheers,
Daave 

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Mark Nottingham
> Sent: Saturday, July 10, 2004 4:51 PM
> To: Tim Bray
> Cc: Atom Syntax; [email-masked]; Norman Walsh
> Subject: Re: Craeted proposal: PaceProvideSchema
> 
> 
> 
> 
> On Jul 10, 2004, at 12:00 PM, Tim Bray wrote:
> 
> > On Jul 10, 2004, at 11:48 AM, Mark Nottingham wrote:
> >
> >>> That would be unacceptable, the schema and the prose have to be 
> >>> consistent. -Tim
> >>
> >> In practice, that's tricky to achieve.
> >
> > I disagree.  The syntax constraints you express in the schema are a 
> > small, tractable subset of the general constraints that 
> appear in the 
> > prose.
> 
> I predict that it will be very difficult to have a one-to-one 
> relationship between the constraints in an XML Schema and prose, and 
> furthermore, that small differences and ambiguities between them will 
> conflict despite our best efforts. This will lead to a long period of 
> sorting out conflicting normative statements in the prose and schema, 
> and errata releases of the specification after we've thought it final.
> 
> Specifying something twice is not a good idea; if you give people two 
> different readings of a constraint, they'll pick one and ignore the 
> other.
> 
> Since people seem to feel strongly about making the schema as well as 
> the prose normative, let's take a look at them after the next 
> round of 
> drafts and see where this approach gets us. If we find ourselves 
> sinking significant resources into aligning them, however, 
> I'd ask that 
> we reconsider such a decision.
> 
> --
> Mark Nottingham     http://www.mnot.net/
> 
>