MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Proposed withdrawal of my NDR suggestions for ABIE extensibility
Hello all,
Based on the Pacific call discussion of the
dangers of opening up uncontrollable
extensibility in all ABIEs, and on Bryan
Rasmussen's (much appreciated, Bryan, thanks!)
research and findings in the area of schema
determinism, I think it is safe to take my
discussion of minor versioning off of the agenda tomorrow.
I now do not see a way of providing minor version
extensibility using W3C Schema syntax.
In private correspondence (thanks Fraser!) the
following article by David Orchard on
extensibility was brought to my attention:
http://www.pacificspirit.com/Authoring/Compatibility/ExtendingAndVersioningXMLLanguages.html
Reviewing David's rules:
1. Allow Extensibility rule: Languages SHOULD be designed for extensibility.
This is laudable, but because UBL has four
distinct namespaces, I don't believe this can be
done at the ABIE level using W3C Schema syntax
(though I believe it could be done using
RELAX-NG). We are already covered at the
extensibility point. But this is moot given the other analysis below.
2. Allow Extensions in Other Namespace rule:
The extensibility point SHOULD at least allow for
extension in other namespaces.
We do have an extensibility point and we do allow
for other namespaces, so I think this is covered.
3. Full Extensibility rule: All XML Elements
SHOULD allow for element extensibility after
element definitions, and allow any attributes.
Because we have four namespaces in UBL I cannot
see how to do this in W3C Schema syntax.
4. Provide Processing Model Rule: Languages
SHOULD specify a processing model for dealing with extensions.
In my discussion paper, the chapter on
deployments illustrates a
"translate-before-validate" step that addresses
this. Using that an application never sees the
unexpected use of extensions (but it also doesn't
see inappropriate uses of extensions that are not
important to the application).
5. Must Ignore Rule: Document consumers MUST
ignore any XML attributes or elements in a valid
XML document that they do not recognize.
This is covered by translate-before-validate.
6. Must Ignore All Rule: The Must Ignore rule
applies to unrecognized elements and their
descendents in data-oriented formats.
This is covered by my suggested use of ##skip
instead of ##lax so as to totally ignore all
descendants of the extension point, even if an
extender chooses to reuse a UBL construct.
7. Must Ignore Container Rule: The Must Ignore
rule applies only to unrecognized elements in presentation-oriented formats.
UBL doesn't allow mixed content, so I believe the above isn't an issue.
8. Re-use namespace names Rule: If a backwards
compatible change can be made to a specification,
then the old namespace name SHOULD be used in
conjunction with XML�s extensibility model.
This is supported in my earlier suggestion that
we do not change the namespace for information items defined earlier.
9. New namespaces to break Rule: A new
namespace name is used when backwards
compatibility is not permitted, that is software
MUST break if it does not understand the new language components.
This would contradict my suggestion that 2.1
information items use a new namespace. David's
opinion would be, then, that as long as 2.1
information items are backwards compatible they
continue to use the same namespace, and only if
the introduction of a new construct requires
something not allowed by the prior namespace,
that it have a new namespace. Since my proposed
translate-before-validate covers this, we are
okay to keep the 2.0 namespace for 2.1
constructs. I can live with that just fine and
abandon my suggestion for a new namespace for new 2.1 constructs.
10. Provide Must Understand Rule: Container
languages SHOULD provide a �Must Understand�
model for dealing with optionality of extensions
that override a default Must Ignore Rule.
I'm not proposing that extensions override the
must ignore rule, so I don't think this applies.
11. Be Deterministic rule: Use of wildcards MUST
be deterministic. Location of wildcards,
namespace of wildcard extensions, minOccurs and
maxOccurs values are constrained, and type restriction is controlled.
It appears my original suggestions did not follow
Rule 11, as pointed out by Bryan, so we can't
have what I thought we needed at the ABIE level.
Conclusion:
So ... based on a read of David's article, I'm
now of the opinion there are no changes to make
to the NDR. Given that all new UBL 2 constructs
are optional, then the translate-before-validate
approach guarantees a must-ignore attitude by downstream applications.
Because of our use of four namespaces for UBL
constructs, I believe we cannot use W3C syntax to
control ABIE-level extensibility, so we stick with the one extensibility point.
My suggested translate-before-validate will
address Jon's concerns about an implementation
not falling over dead when it sees a new
construct (because it actually never ends up seeing the new construct).
It does mean that Paul's concerns are not being
met as expressed in Brussels regarding a network
deployment of heterogeneous schema validators all
indicating UBL 2 namespace for instances will
fail on 2.1 instances using the UBL 2 namespace
unless they do their own
translate-before-validate ... which, as noted
above, will create some false positives if the
translation throws away non-conformant constructs
resulting in a conformant instance.
Thanks again to the feedback regarding my
straw-man proposal for versioning ... it has
helped me understand a lot, and I hope it was
considered constructive even if it has to be removed.
My discussion of UBL Customization in my paper
still stands, though ... I will revise my
discussion paper to remove the discussion of minor versioning.
Now, my question is, does anyone disagree with
this analysis and feel we should not remove this
discussion from the agenda and keep talking about it? :{)}
. . . . . . . . . . . Ken
--
Registration open for UBL training: Montr�al, Canada 2006-08-07
Also for XSL-FO/XSLT training: Minneapolis, MN 2006-07-31/08-04
Also for UBL/XML/XSLT/XSL-FO 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]