"The Namespace Discussion" on ISO/IEC 29500

[Alex Brown]

Shawn hi 

> Again, it's going to come down to how the implementers decide 
> to deal with unexpected data.

Yes, and I think something we can all agree on is that this whole debate
puts into sharp focus what it means to be "forwards compatible" (or
not).

(And, BTW, this is also a big problem for ODF. Not currently our
problem, though it may become the problem of some implementers here).

> For example, if an 
> implementation runs across the compliance attribute ( not 
> part of Ecma 376 1st ), the implementer will need to decide 
> to abort the open, to ignore the attribute and continue 
> opening the file, etc., etc.

As a validation purist I might say that applications should not process
invalid XML inputs (for that is what we would have here). But I can
appreciate some may find that an overly harsh approach. At the very
least, a user must be *aware* they might suffer data loss, I think.

> From what I've seen so far -- 
> clearly not scientific -- is that most implementations deal 
> with unexpected data loosely and hence can successfully open 
> the file; in these cases, the implementations attempt to 
> retain every bit of understood data they can; data which is 
> [not] understood is lost at open time.

This is always dangerous though: a publishing example is the
@legal-embargo="true" attribute that gets introduced on an element. We
may think we "understand" that element's content still, but because we
don't understand the attribute, in fact we miss the fact that the new
context modifies the meaning we assumed.

In general it is simply not possible to write software which will
reliably deal with formats from the future (unless we had some way of
indicating the semantics of elements/atttributes in a pre-agreed way:
now there's an idea -- can we annotate the schemas with concepts like
"must-understand" for certain constructs?).

So, in general, the fail-safe method is to reject an invalid input.
 
> To be clear, this is an implementer's choice.

Or, to be more precise, it _was_ an implementer's choice. The software
is already out there which is going to be shown these new files
(especially if we don't resolve the media type and filename extension
issues -- another aspect of this).

One of the other things we agreed on in Prague (and which didn't make it
into the document) was that we can't travel in time :-) This wasn't just
for fun -- the fact is that we have major implementations out there like
Office 97 and OO.o 3.x which will not deal gracefully with "formats from
the future" which they wrongly treat as *their* formats.

> From a 
> technical perspective, the implementer can write more code to 
> improve the experience.

Sure, and I'm guessing there is a possibility of patching some
installations to make them compatible with future formats.

>  Like many of these decisions which 
> we defer to the implementer, this will be a great opportunity 
> for innovation and competition.  

It's an interesting one. Some users will be utterly dismayed by seeing a
dialog box which informs them a document can't be opened. Other users
(perhaps those with the highest value documents) would actually prefer
such a dialog, and would be horrified by the thought of silent data loss
in their (say) financial spreadsheet.

We're all user-focussed here, I think. What we're trying to reach
consensus on is the approach that will best serve those users ...

- Alex.