|
| | | Altova Mailing List Archives>Archive Index >xmlschema-dev Archive Home >Recent entries >Thread Prev - Re: multiple namespaces [Thread Next] Re: Permit (greedy) conflicting wildcardsTo: <noah_mendelsohn@--.---.---> Date: 4/24/2007 1:13:00 PM
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@u...>
To: "Pete Cordell" <petexmldev@t...>
Cc: <xmlschema-dev@w...>
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
> --------------------------------------
>
>
>
>
>
>
From petexmldev@t... Tue Apr 24 11:41:56 2007
Received: from aji.w3.org ([133.27.228.225])
by frink.w3.org with esmtp (Exim 4.50)
id 1HgJP9-0003MT-L6
for xmlschema-dev@l | |
| | ||||||||
| Company | Legal | Press | Partners | Careers | Sitemap | Contact Us | Altova Blog | Mobile | Full Site | |||
|
