[standards-jig] Essence of Jabber

Julian Missig julian at jabber.org
Thu Mar 7 20:44:26 UTC 2002


On Thu, 2002-03-07 at 08:30, Daniel Veillard wrote:
> 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.

Yeah, I understand. I just assumed "don't break on unknown extensions -
just ignore" was supposed to be more of a parser-level rather than
application level, but yes, it should be application level too. I was
just emphasizing that we want to be sure we mention that the parser
should be XML compliant (I know some clients had non-validating
"parsers" which crashed on unknown elements...)

Julian
-- 
email: julian at jabber.org
jabber:julian at jabber.org




More information about the Standards mailing list