RE: [XMLVersioning-41] Comments and Suggestions on Draft Extensibility Finding


I sent you a very quick reply a few days ago.  I've now read your note in 
more detail, and so can comment a bit more carefully.  I'll just offer 
some highlights here, and we can discuss the finer points f2f next week.

> the "e/v pendulum" swung too far from the 
> HTML style of extensibility to the "draconian
> error-handling" side.

Overall I agree.  Stated differently, many "customer" vocabularies are 
being designed with insufficient attention to the need for evolution, and 
the generalized mechanisms and guidance to support such evolution are 
often missing.  On the other hand, many W3C vocabularies including WSDL, 
SVG, etc. have been providing for open content and processing models to 

> To a great extent, my goals have been to push 
> the e/v pendulum back towards the middle.
> ...
> Hence I am also leery of moving the extensibility 
> and versioning finding away from a "pro-e/v" message 
> until I see XML based systems being regularly built 
> that are too extensible or too versionable.

You seem to argue for an imbalanced presentation because of where the 
pendulum is today.  On that I disagree.  I think TAG findings should stand 
the test of time and should offer wise guidance that will seem appropriate 
in any year.  We should not be shy about discussing the downsides of 
extensible vocabularies as well as the benefits.  I stand by what I said 
originally:  "extensibility is a tradeoff and we need to explain both 

>  (paraphrase)  we agree completely on #2 (need 
> to give a clear story on namespaces and 
> versioning/extensibility) , #3 (dealing with partial
> understanding)

Excellent.  Those are key points.  I think you and I could spend some 
profitable time at the f2f talking about the partial understanding 
question:  as I wrote in my original note, I'm not as optimistic as you 
that mustIgnore and substitutions are quite the best starting point for 
dealing with partial understanding, though I do grant their importance for 
modeling key aspects of processing.

> mostly agree on #5 (relationship of
> syntactic to semantic extensibility.

Good.  I hope we can find effective ways to at least raise the issue, and 
maybe provide guidance.

> partially agree with #4 pending my comments within

(#4 was my laundry list of suggested general guidelines.)

Fine.  As I mentioned, I don't consider these to be entirely defensible in 
detail. Rather, I think they are representative of the sorts of general 
goals we should state explicitly and against which we should measure 
particular XML or schema idioms.  I think the general guidance will be as 
useful as syntactic details for those designing vocabularies.

> the more abstract the discussion, the smaller the 
> audience or the less useful particular audiences will
> find the material.

We don't entirely agree.   "Cool URIs don't change" and  "agents should provide URIs as identifiers for resources" [1] are very broad bits of advice, but in some ways they're more useful to a 
broader range of readers than, for example, a detailed look at ways of 
exploiting URI syntax.  We have WG Recommendations and Notes for the 

I think we're getting preliminary feedback that AWWW is at a level that 
many readers find useful.  While I'm not necessarily against having 
findings that go into more detail, I think extensibility and versioning is 
an area where the community will benefit from a careful elucidation of 
high level principles. 

> When I have presented at conferences on 
> the topic, the audience has very much 
> appreciated the focus on XML Schema. 

Sure. My concern is in part about the proper role for the TAG, and as I 
said, I prefer that we focus on the big picture.  Backing that with 
details is fine, though I'm less happy focussing on the details of a 
particular recommendation (Schema 1.0) for which the responsible workgroup 
has in its charter to do a new version that will deal with versioning 
better.  Helping with details of Schema 1.0 challenges is a great thing to 
do in W3C Notes, primers, magazine articles and blog discussions;  I'm 
less convinced that it's the right focus for the TAG. 

That said, I completely agree that the big picture needs to be thoroughly 
grounded in the details, and that it's sometimes appropriate for us to get 
into detail. 

I should acknowledge that your focus on mustIgnore and substitution 
mechanisms is in part an attempt to do just that.  The problem I have is 
that, by working somewhat bottom up from syntax to model, you have been 
drawn into an analysis that misses the fundamental importance of partial 
processing (my point #3.)  Dealing with varying degrees of understanding 
seems to me to be the key to a realistic finding on extensibility and 
versioning.  Almost every specification I've seen that supports open 
content has an explicit model for this.  Indeed, I was just looking at the 
SVG Rec and it says [2]:

"Additionally, SVG allows inclusion of attributes from foreign namespaces 
on any SVG element. The SVG user agent will include unknown attributes in 
the DOM but with otherwise ignore unknown attributes."

So, even the foreign stuff is explicitly contributing (I.e. to the DOM). 
Looking at the details of real systems is indeed important, but we need to 
carefully extract and explain the right higher level principles. 

I am looking forward to talking to you about all this starting tomorrow. 
While it takes more space on the page to discuss disagreements than 
agreements, I still believe that our views on this are largely consonant, 
and that the question is primarily to decide what (if anything) is the 
right emphasis in a TAG finding.



Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

Received on Sunday, 27 February 2005 18:00:23 UTC