Re: [ubl] Namespace URI string implications

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Based on Jon's comments in the call that this is such a sensitive 
issue, I've been trying to think of a compromise "middle ground" that 
would be palatable to everyone.

At 2006-06-06 01:10 -0400, I wrote:
>(1) Deployment of a heterogeneous system
>  - there is no way we can shut down global UBL usage of a 2.0, 
> deploy 2.1, and start the world up again
>  - a system that has upgraded to 2.1 will forward what they 
> consider to be a UBL valid instance, since it validates in their 
> system against the published 2.1 schemas, to a 2.0 system, and the 
> 2.0 system will reject it for non-compliance to the UBL schemas 
> they are using that are
>...
>A possible mitigation as I write this is to use a 2.1 namespace URI 
>string but us it *only on the elements that are new to version 2.1* 
>and not on the document element.  But this will mean we must 
>introduce a namespace-based exorcism step in the deployment of UBL 
>applications where a "filter" step that is engaged after receipt of 
>a message will preserve information items in the UBL namespaces that 
>are supported by a given deployment, and elide the information items 
>that are not supported.

I've been experimenting with this filter and it happens to fit quite 
well into the development of a UBL application and accommodating 
subset definitions.  But what is new is that now schema validation is 
not the first front-line step, rather, it is a second step after the 
well-formed XML document as received has been processed to remove 
unwanted constructs (as recognized by their namespace not being in a 
list of "desirable" namespaces).

Paul, is there such a concept in your ASN.1 world of being able to 
"wash" an instance before applying validation?  That is, removing 
constructs you are not interested in before determining if the 
constructs you have left over are acceptable?

>But it means that we still need to introduce new namespace URI 
>strings in order to distinguish the new information items of 2.1 
>from the old information items of 2.0.

Namespace-based filtering using XSLT or SAX is very quick and 
straightforward as it means the filtering programs can be written 
without knowledge of structure, only of the namespace URI strings.

It turns out that a complete XSLT stylesheet taking in an external 
file declaring "desirable" namespace URI strings and filtering an 
input file to the output is only fifteen XSLT instructions.  This is 
not rocket science, but it is a philosophical change of attitude 
towards the meaning of the namespace URI string of the document 
element (not of the new information items).

>I've written this very quickly in order to get the debate started 
>... I apologize if I've missed something obvious.  On the call it 
>seemed important that this be discussed quickly.

Still scrambling with ideas here, but I'll proceed with my paper on 
the premise that we move schema validation away from the front line 
and only use it after an instance has been filtered for those 
namespaces needed for a subset.

I think this might be a middle ground between those who think that 
*any* change to the model necessitates a namespace change to the 
document element, and those who think the namespace cannot change in 
order to preserve the longevity of UBL applications.  This scheme 
would not change the namespace of the document element but would 
change the namespace of new information in the evolving suite of UBL 
information items.

Still looking for feedback, but I'll continue writing my paper so 
that I can present the entire scenario.

. . . . . . . . . . Ken

--
Registration open for XSLT/XSL-FO training: Wash.,DC 2006-06-12/16
Also for XSL-FO/XSLT/XML training:    Birmingham, UK 2006-07-04/13
Also for XSL-FO/XSLT training:    Minneapolis, MN 2006-07-31/08-04
Also for XML/XSLT/XSL-FO/UBL training: Varo,Denmark 06-09-25/10-06
World-wide corporate, govt. & user group UBL, XSL, & XML training.
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Aug'05  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal