Re: Permit (greedy) conflicting wildcards

I think semantics are essential, but I also believe semantics should have a 
clean representation in the syntax.  To me, a wild card specification should 
be specified wholly in a wildcard construct (xs:any).  If you have to start 
coding up things such as:

        <choice>
                <element ref="html"/>
                <any notQname="##defined"/>
        </choice>

to get the sorts of wildcards you want, then I think the syntax is wrong.

IMO it's better have:

    <any notQname="##definedLocally"/>

for this that want it, and:


    <any notQname="##definedGlobally  ##definedLocally"/>

for those that want that.

This is very much your building blocks theme, building up the wildcard spec 
you want, rather than starting (in the ##defined case) with an over 
prescribed wildcard and then using work arounds to prune it back to what 
some might want.

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML Schema to C++ data binding visit
 http://www.tech-know-ware.com/lmx/
 http://www.codalogic.com/lmx/
=============================================

----- Original Message ----- 
From: <noah_mendelsohn@us.ibm.com>
To: "Pete Cordell" <petexmldev@tech-know-ware.com>
Cc: <xmlschema-dev@w3.org>
Sent: Monday, April 16, 2007 2:57 AM
Subject: 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 Tuesday, 24 April 2007 11:13:20 UTC