[standards-jig] Essence of Jabber

Daniel Veillard veillard at redhat.com
Thu Mar 7 13:30:03 UTC 2002

On Thu, Mar 07, 2002 at 01:16:42PM +0100, Fabrice DESRE wrote:
> Julian Missig wrote:
> > On Thu, 2002-03-07 at 03:42, Fabrice DESRE wrote:
> >  > Julian Missig wrote:
> >  > >  >
> >  > >  > - don't break on unknown extensions - just ignore
> >  > >
> >  > > Again, XML compliance.
> >  >
> >  >   I disagree here. XML compliance doesn't disallow an application to 
> > stop
> >  > processing when the document is invalid. It is an application defined
> >  > behaviour.
> >  > XML compliance just forbid the processing of a document that is not well
> >  > formed.
> >  >
> > 
> > Huh? Not breaking on unknown attributes or unknown elements is a part of
> > XML, especially when we are not checking for validity, only
> > well-formedness.
>   That's what i'm saying... XML compliance only deals with the syntactic 
> level of the stream (the raw markup), not with the semantic of the 
> protocol. So saying that "XML compliance tells to ignore unknown 
> attributes or elements" is not correct. It is an application design choice.

 Fabrice is right :-)

The XML specification defines the processing model of an XML parser, not
how an application must process the events from the parser. A fatal error
forces the parser to stop producing "data" events. A parser can also raise
"errors" which may or may not be recovered by an application.
 Some of the parser errors like missing entities in not-standalone documents
must be reported but are in general recovered from. The initial case which
raised that thread is when the semantic of some of the document markup
are not understood by the application, this may result in an application
error, but won't be caught by the parser. It is not an XML conformance
error, but could be a Jabber conformance error (if defined as such, in some
case like the x element, one precisely doesn't want to get a conformance error
for child of such tree) but when to raise such error on unknow markup 
semantic should be closely looked at.


Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard at redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

More information about the Standards mailing list