MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ubl] Namespace URI string implications
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]