Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Feature Manifest (Was:RE: Parser Behaviour (serious))
 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@x...&BODY=unsubscribe%20xml-dev List archives are available at http://xml.org/archives/xml-dev/ *************************************************************************** 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
