DR-08-0012 Namespace Mapping Table v2

[Alex Brown]

Rick hi

> The BRM voted for a "transitional" class that is a superset of ECMA
> 367-1, and a "strict" class that is a superset of the transitional.

.... I assume you mean "subset of the transitional"  ...

I'm not sure NBs were so explicit, or even so conscious of the
implications of their actions; but if this is what they wanted, it's not
what they've got because of issues such as dates, percentage
representation and measurement representation - and probably some more
not yet discovered ...

>  So an application that
> implemented the transitional
> schema could process both ECMA 367-1 and IS29500-strict documents
> (raggedy differences
> aside.)   And so that, even outside conformance, the same application
> could make a good
> stab at handling both files.

True for applications written with the foreknowledge that they needed to
do that. But for existing applications out there, they will silently
corrupt data as we saw in Prague.

Any developer writing handling code for "having a stab" will also be
capable of remapping the namespaces -- I don't see this Namespace change
as having an impact on those users, it is aimed at is the non-technical
user loading strict documents into a legacy application.

But as I've also said elsewhere it's not as if this Namespace change was
"clearly right" and other solutions "clearly wrong" -- it was a balance.
I feel we are now re-visiting exactly the issues over which WG 4 has
spent a lot of time, and that this is not an issue on which members are
going to reach 100% agreement. But we had already reached a consensus.
 
> The current direction being suggested turns that on its head, it seems
> to me.

Well, if we look at (Canadian BRM delegate) Tim Bray's blogs
http://is.gd/scVR , we can see that he considered S (which he considers
represents the "ISO Delta") to be "completely irrelevant to the
marketplace", something that "won't be usable by the deployed base of
software" -- so the intention in his case was clearly NOT that S was
something the applications would have "a stab" at! Rather, it was
something applications would actively avoid. 

I think we're risking getting a little too grand too soon here. The
current issue before us is the Namespace change which is a response to a
defect report from CH, decided by WG 4 as the best technical solution.
We are currently dealing with one of what Rick calls the "raggedy
edges".

Yes, we should also be thinking forward and be discussing the wider
question about the relationship between S and T, but that is a much
bigger topic and I think much more evidence and many more points of view
need to be heard before we can begin to start thinking about
decision-making in this space. I think Mohamed's question about *actual*
implementers is the way I'd like to see us working on this: calm,
exploratory, evidence-based -- making statements or guesses about what
the vote will be and working back from that is a recipe for chaos.

- Alex.