XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] a namespace definitions related question(s)

Shlomo Yona writes:

> So the processor is still expected to issue a "not well formed"
> message, but might still tolerate the result?

I'm not sure there is a rigorous meaning for "tolerating" a result.  You 
can write or purchase software to do all sorts of things.  What's clear is 
that the specifications say that your document is not well formed.  If you 
get hold of a piece of software that claims your document >is< well 
formed, then that software does not conform to the XML Recommendation, or 
specifically, it does not correctly implement the well-formedness relation 
defined therein. 

Now, what does it mean to "tolerate" that not well formed file?  Not crash 
with a stack trace?  Maybe.  Tell your application:  "this is not well 
formed XML, but you might want to fool with it anyway"?  Maybe, but 
presumably that's only a good thing to do if your application has good 
need to try to work on even non-well formed XML input.  If your 
application is an XML editor, then there may be good reason for it to take 
in the document, flag the suspicious parts (the mismatched tags), and keep 
going. 

So, we on this mailing list can't tell you what software will meet your 
needs.  We can point out, as I did in my note just sent, that the 
pertinent specifications define pretty clearly what is and is not well 
formed XML, when namespaces and schema recommendations apply, etc.  What 
we can do is suggest that when your software accurately reports on how 
your documents do or don't conform to what those specifications say, that 
software is in that sense conforming.  Beyond that, the specifications 
don't have much to say, and you need to get software that meets whatever 
your needs are.  As I say, if you're writing an XML editor, for example, 
there may be good reason to keep going even when the input file is "buggy" 
(not well formed).

That said:  for most purposes, the reasons we have carefully defined tests 
like well-formedness is so that downstream software will be warned 
consistently when input looks bad.  From that perspective:  no, your 
software should not in general "tolerate" bad XML.  It should say:  this 
is buggy, and you shouldn't proceed.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS