[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]