xml-dev - Re: Feature Manifest (Was:RE: Parser Behaviour (serious))

[Peter Murray-Rust <peter@ursus.demon.co.uk>]

At 12:41 AM 4/8/00 -0400, THOMAS PASSIN wrote:
>To help anyone interested to get started on Peter Murray-Rust's proposal
>about reviewing the various combinations of parser behavior in the xml rec,
>I have pulled out all (I hope!) behaviors that are specified with "may" or
>"at user option".  I didn't indicate the section each piece came from, but
>that's not hard to find.  The text that relates most closely to the concern
>that Peter originally expressed is, I think, the following:
>
>"If the entity is external, and the processor is not attempting to validate
>the XML document, the processor may, but need not, include the entity's
>replacement text. If a non-validating parser does not include the
>replacement text, it must inform the application that it recognized, but did
>not read, the entity."
>
>The whole list is a little long for one of these postings, but here it is:
>
[... list snipped ...]

I think this is extremely helpful. 

Among the successful mechanisms that we have used in the past (including
for SAX and "XSchema") is for a person to coordinate Q and A to the list,
with *private* replies to that individual. This avoids long documents being
repeatedly posted to the list. So if person X has had greatness thrust upon
them, it works like this:

X: 
	"We'd like to see if there is a substantial body of opinion that feels
that ... would be useful. I (or we) would be grateful for private mail
answers to:
	1 Would you find it useful to have Z?
	2. If so, should it be of the form Y or Q...
	3.

Then X receives a bundle of mail and *in a few days* reports back 
	1. "Most people (unattributed) feel that it would be useful
	2. The following mechanism have been suggested
	3.

The positive side of this is that the activity is carried out "on the list"
but without the traffic becoming impossible. [I think this is an area where
we don't want another flavour of XML but - at least in the first instance -
a means of interpreting the essence of the spec and the wishes of users. It
can also move very fast. The negative side is that it's a lot of work, and
the process depends on the constancy and patience of an individual (perhaps
a small group). 

The dynamics of this can be found in the SAX discussions 2 years ago.
Perhaps Leigh could point us to the archives, ( I have also abstracted them
but the server is down). In that DavidM composed a careful set of questions
and took us through them on a roughly 3-day basis. 

My sense is that we have the same groundswell now that we did then. I am
not anticipating any particular outcome. I do, however, think it would be
extremely useful to be led through and see if we can find communally. This
could be:
	- the problem is one of perception and that a clear statement reassures us.
	- the problem is one of interpretation and these are the options
	- the problem is one of implementation and these are the tools that need
to be built of deployed
	- something else :-)
	- there is a problem and we cannot find a solution

At the moment I would expect a mixture of 2 and 3.

If Tom would like to do this, he has my full support. I am only an
individual, of course. Other suggestions welcome.

	P.

[NB. I shall be off air for a few days, so don't take silence as lack of
interest.]





***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************