[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Agenda for Atlantic UBL TC call 7 June 2006
At 2006-06-06 14:28 -0700, jon.bosak@sun.com wrote:
>NDR WORK SESSION
>
> Namespace URIs revisited (oh no!):
First, apologies for bringing this topic up yet again ... I don't
remember participating in the related discussions earlier, which I
know doesn't give me the right to bring them up now, but I'm trying
to address the rubber-hits-the-road implementation issues and I see
real problems now that we have a more mature idea regarding
deployment. These came to light for me in the Brussels discussions
when I heard such strong opinions.
> http://lists.oasis-open.org/archives/ubl/200606/msg00004.html
> http://lists.oasis-open.org/archives/ubl/200606/msg00005.html
> http://lists.oasis-open.org/archives/ubl/200606/msg00006.html
> http://lists.oasis-open.org/archives/ubl/200606/msg00007.html
> http://lists.oasis-open.org/archives/ubl/200606/msg00008.html
> http://lists.oasis-open.org/archives/ubl/200606/msg00009.html
A quick summary:
We have strong feelings expressed from two ends of the namespace
practices spectrum:
End 1: "all namespace URI strings for UBL 2 should remain the
same through all additions to the vocabulary and any
changes in the available document components are
determined by a version element at the start of the
document"
End 2: "every time anything in the set of available information
items in the document is added, the entire document
needs a new namespace URI in order to engage the
appropriate document model for schema validation"
I think I've boiled down the issues from what I heard from the two
ends in the Brussels discussions with stakeholders:
Intractable requirement for End 1:
"why change a working application just because someone
somewhere is allowed to use a new information item that
is not important to me!"
Intractable problem for End 1:
"the validation of an XML document happens before an
application has the ability to look inside of the document
for any version information, so a 2.1 instance sent to
a 2.0 application will fail at validation before the
application even gets a chance to look inside to see it
is a verison 2.1 instance"
Intractable requirement for End 2:
"without a one-to-one association between the namespace
URI of the document vocabulary and the document model with
which to validate the document model, it is impossible to
know which set of constraints to use for successful
document validation"
Intractable problem for End 2:
"in a heterogeneous deployment of different document
models, serendipitous blind interchange of UBL instances
will not happen because the sender would have to know
the namespace of the document model supported by the
receiver"
I'm writing up a proposed middle ground:
"when an information item doesn't change in the UBL suite,
its namespace URI doesn't change; when a new information
item is added to the UBL suite, it is given a different
namespace URI to indicate that it is a member of a new
supplement of a number of items to the UBL suite"
From the application's point of view:
"a filter-before-validate phase ensures the program receives
only those constructs for which the application was developed
and validation constrained, thus allowing the blind acceptance
of an augmented UBL instance without changing a single line
of the filter code or the application; the filters don't
indicate what is to be removed, they indicate what remains,
thus the filters and application are in lock-step and neither
one needs to even know that augmented information was in the
original document, though this could be determined because
there are now no barriers for the application to look inside
at the version information item."
From the network point of view:
"interchange between parties who are aware of and expect
to use the new facilities in the augmented UBL suite can
base their validation on the augmented document models
that have constructs the old namespace URI and constructs
with the new namespace URI and thereby take advantage of
new features; meanwhile, interchange between a party who
happens to be using the augmented model can still occur
with a party whose application happens to be using the
lesser model because by the time the validation happens
with the lesser model, only those information items with
namespaces expected by the application are in the filtered
instance, thus the application finds everything it needs
without anything disturbing validation."
I think that sums it up.
I doubt that I will be finished my write-up in time for tomorrow's
meeting; certainly it won't be in time for people to consider before
tomorrow's meeting.
Note the above doesn't deal with subsets, but it happens the
filter-before-validate solution addresses one of the challenges I had
for subsets as I will describe in my paper.
I will try to be on the call, but I may be late arriving (apologies
in advance) because of a medical appointment.
. . . . . . . . . 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]