Comments on: Must-Ignore and Must-Understand

By: THOUSANDMINDS » Making Mistakes with XML

THOUSANDMINDS » Making Mistakes with XML — Tue, 07 Feb 2006 11:54:02 +0000

[...] One approach is to include attributes such as version and compatible-with in your elements. The values of these attributes can indicate what version of your language an element comes from, and what versions an element is compatible with. This affords applications an opportunity to take some more intelligent action based on what they receive and what they generate. Another approach is to leverage the “must-ignore/must-understand” design pattern (although it suffers some shortcomings). [...]

By: Rasmus Kaj

Rasmus Kaj — Wed, 30 Nov 2005 11:18:07 +0000

Actually, there is two different way to “ignore” an element as well, to complicate matters further … Either you can ignore the element and the contents of that element (as you do in your example), or you can ignore the element and treat the child elements as beloning to the parent element (like in html).

Or actually, there’s a third possibility; just treat the element as an element with no semantics (differs from method #2 in how selectors work on child elements to the unknown element).

By: Bill de hOra

Bill de hOra — Mon, 21 Nov 2005 00:12:30 +0000

mU/mI are a way to tunnel evaluators through XML. It’s like obfuscated code-sharing

Atom is different insofar as the best thing to do with it is squint your eyes and try and see the serialization of a dictionary. It’s by-design additive, so it makes no sense (imo) to hobble it with mumi directives - indeed it would be nuts - imagine throwing a runtime exception because a hashmap has keys you can’t dispatch on. Atom drags the XML crowd about halfway to RDF.

By: John Cowan

John Cowan — Thu, 17 Nov 2005 18:02:31 +0000

Absolutely.

By: david

david — Thu, 17 Nov 2005 13:11:39 +0000

Thanks for the comment, John. I agree with what you write, but only in reference to a specific processing context. The elements that an application must understand to complete a business transaction are not necessarily the same elements that an application must understand to index a document for search, or to format it as PDF.

By: John Cowan

John Cowan — Thu, 17 Nov 2005 12:30:53 +0000

It seems to me that the true meaning of “must-understand” conventions is this: if you get something that is implicitly or explicitly marked “must-understand”, then if you don’t understand it, you don’t understand anything else either. The fact that Atom has no “must-understand”, and treats everything not documented as belonging in an Atom document (even things in the Atom namespace) as “must-ignore” means that no new Atom element can change the intended semantics of an existing Atom element. (Tim says this is okay with him/them.)

But if adding a new element might change the purpose of old elements, then “must-understand” is a sensible notion: RELAX NG and XML Catalogs are “must-ignore” for elements and attributes outside the RNG namespace, but “must-understand” for things in the namespace: if you see a (currently unknown) element, you are probably trying to process a new version, and all bets are off as far as the interpretation of existing elements. (Just my opinion, not attributable to any OASIS TCs.)

By: Uche

Uche — Thu, 17 Nov 2005 05:54:34 +0000

If I understand you rightly, Walter Perry has been saying this sort of thing for years, and I think it’s a very important insight for making sure that XML is not too strongly tied to far more ephemeral application models. Schematic and modeling systems should basically talk about what they know to talk about, and not try to philosophize about every possible hypothetical characteristic of data in the system. It’s up to the application layer to use the right modeling tools to satisfy the *local* business semantics.