Re: Permit (greedy) conflicting wildcards

Pete Cordell writes:

> > Pete Cordell writes:
> >
> >> I think it will be possible to find many cases where such an
> >> extension does not make sense.  But I also think that it will
> >> be possible to find many cases where it does make sense.
> >
> > Sure, but you can always allow for it.  For example, you could do:
> >
> >        <choice>
> >                <element ref="html"/>
> >                <any notQname="##defined"/>
> >        </choice>
> 
> Is this intended to be the syntax for a version 1 schema?  i.e., I 
design my 
> schema thinking that I probably don't want <html> here (otherwise I 
would 
> have put it in more formally), but I'm leaving scope for it in the 
future by 
> putting it into this choice (which as you say, could be a group)?
> 
> That would seem very ugly to me.

You say you're asking about syntax, but then most of your comment seems to 
be as much about the semantics.  Anyway, on semantics, the answer is:  I 
think so.  Formally, the workgroup offers its designs in working drafts 
and I don't think we've yet put out one advertising this syntax (I'm out 
of network range at the moment and can't check), but I think the 
notQname="##defined" is along the lines of what will probably be proposed 
for the wildcard.  The <choice> is just an example I made up for purposes 
of these emails to show what you can do if it meets your needs.  If it 
doesn't, then don't use it.


> > Many other strategies are possible.  For example, instead of the ref 
to
> > the HTML element, that could be a reference to a group with a choice 
of
> > several elements.  The point is, if it's in your schema, you tend to 
know
> > about it, and can reference it if you want to allow it.
> 
> ...Unless you make a mistake in V1, or new use-cases arise.  In my 
> experience most schemas are not perfect in their first incarnation. 
> Otherwise why would you need a V2?

It seems to me that it's in the nature of schemas that you have to make 
some limiting decisions when you deploy the first version of your schema. 
After all, you could decide later that you regret almost anything in your 
V1 language.  So, maybe you regret the choice or root element or its 
namespace.  Maybe you completely messed up the content models of all your 
elements.  I think the only way to be sure your V1 will accept any 
possible V2 revision is to have it validate >everything<, in which case 
there's not much use for schemas at all.  Conversely, we've heard from 
users who have good reasons for going to the opposite extreme, I.e. for 
writing V1 schemas that reject everything that doesn't have a first class 
interpretation in the V1 language.  Those users don't want the schema to 
allow for any extension points.  They either want to use mechanisms othre 
than schema to handle the versioning (perhaps they transform V2 instances 
before validation) or they propose to run schema validation in as yet 
unseen modes that would report something in the spirit of:  your document 
isn't valid, but if only you'd leave out certain elements that appear to 
be extra, it would be.  Using these models, the V1 schema provides no 
overt extensibility at all.

I say all this because you're right that examples like the one given do 
represent a conscious decision on the part of the V1 designer as to what 
sort of future proofing he or she is trying to do.  One things that's 
clear is that different users will want to work in different styles.  I 
wouldn't push the choice above on anyone who found it unnatural, but I 
think it's a plausible example of what some users might want to do.

In any case, whatever new wildcards or other mechanisms we come up with in 
Schema 1.1 are just tools, building blocks that some users will use in 
certain ways, other users will use in other ways, and other users will 
find unhelpful.  These are just my opinions, not speaking officially for 
the WG or anyone else who may be in it.  Thank you.

Noah


--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Monday, 16 April 2007 01:57:26 UTC