[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: SV: [ubl] Revised discussion paper on UBL 2.0 subsets, extensions, versions, validation and interchange
Thank you, Bryan, for your post. At 2006-06-20 11:04 +0200, Bryan Rasmussen wrote: >I don't think this makes any sense: > > <xs:element ref="u:Extension" minOccurs="0"/> > <xs:element ref="u:OrderNumber"/> > <xs:element ref="u:LineItem" maxOccurs="unbounded"/> > <xs:element ref="u:TotalAmount"/> > <xs:group ref="u:FutureVersions"/> > >If we were allowing basically any at the end of the sequence then we would >have both the Extension as an Any, and at the end of the sequence Any >allowed? The only difference is that u:Extension is of course an element. Right ... but the FutureVersions group is for minor version use only and not for subset use (customization). Customizations would still be required to use the extension point for its declarations. Unfortunately, there is no way to *enforce* candidate users of UBL not to use the minor version extension area for their own purposes ... there is no way to police the use of the end of each ABIE. While we as a committee mandate that it be used only for minor versions, we can't control that in a schema. What was brought to my attention in the meeting last night was that regardless of whatever rules we state in prose regarding the use of the minor version wild card area, since we cannot enforce it with schema expressions, we can expect it to be abused by users who throw their own constructs in that area. I had not anticipated such abuse since the introduction of a user extension in the future version area would throw off future validation possibilities. User extensions belong under our defined extension point. >Why not if that was the case use > > <xs:group ref="u:FutureVersions"/> > <xs:element ref="u:OrderNumber"/> > <xs:element ref="u:LineItem" maxOccurs="unbounded"/> > <xs:element ref="u:TotalAmount"/> > <xs:group ref="u:FutureVersions"/> Because the use of ##any at the start of a group of content particles will eat all of the content particles before hitting the required content particle ... when the processor then hits the need for the required content particle, there will not be any left and the processor will fail validation. Is there a processor that accepts what you show above to be acceptable for validating my test? Perhaps I am mistaken ... but at this late stage I think it is important that we only talk about functioning code and not just suppositions. My paper is accompanied by the test files I've used, so I tried the above that you are advocating and I see that with Xerces my expectation for particle usage is correct. Which processor are you using that allows the above? >or > > <xs:element ref="u:Extension" minOccurs="0"/> > <xs:element ref="u:OrderNumber"/> > <xs:element ref="u:LineItem" maxOccurs="unbounded"/> > <xs:element ref="u:TotalAmount"/> > <xs:element ref="u:Extension" minOccurs="0"/> I'm making a distinction between user-defined extensions (the element extension point u:Extension), and committee-defined minor versions (the group u:FutureVersions). My suggestion for the extension point is solely for user-defined extensions, so the document-wide extension point at the start of the document is sufficient to this purpose. When I considered user-defined extensions at each element, they were not under an extension point (since the constraint expression would be awkward to change at each use), and I experimented with W3C Schema expressions for declarations of extensions and it was not pretty. So, I believe it makes sense that user-defined extensions remain solely under the extension point use of ##any, and that committee-defined minor versions go only under the ##any that I'm introducing at the end of every ABIE. But during the call last night it would brought to light this would be opening a can of worms for those users of UBL who did not follow our guidelines and who put their own constructs at the end of ABIEs. >This is not an endoresement of using the methodology you've shown in your >paper which I worry will cause implementation problems, and am not completely >sure if moving the Html method of handling unknown markup to a business >markup standard is a good idea, it's somewhat untried. But that is an issue >for a later post, although I might after thinking about it further become a >fan of the solution but right now I am worried. Remember that the HTML method of handling an unknown element is to process the children of the element ... I'm certainly not suggesting that (nor is that easily constrainable in a schema expression). How would you characterize the implementation problems you think might be in play? >Also if I understand what you're suggesting I think we could end up with >nondeterminism, for example if you had > > > <xs:element ref="u:TotalAmount" minOccurs="0"/> > <xs:group ref="u:FutureVersions"/> > >With this wouldn't you end up with a situation where u:TotalAmount either has >to be validated as the default validation of the validator, prob. strict, or >skipped, and how would you know which it was? I believe the particle determination is unambiguous. Do you have a running example illustrating there is a problem with the above? I understand the validation will deal with the particles in the order received, and since there is no choice group I don't think there is an opportunity for non-determinism. >basically this is one of the reasons for using, instead of ##any namespace, >##other namespace, The limitations of W3C Schema semantics won't allow me to say "##other" of the four UBL namespaces ... only the one given namespace ... I can say that in RELAX-NG but not W3C Schema. But, then again, my objective for uhe u:FutureVersions group was to reserve the bucket for future UBL use of new UBL namespaces, so I don't believe your suggestion will handle the requirement. >however other namespace usage CAN also lead to >nondeterminism in cases where the sequence can hold elements in namespaces >other than the target namespace of the schema where xsd:any is used. I'm not >sure how often these kinds of problems would arise, obviously would need NDR >rules to keep it from happening if this methodology where to be chosen. Really? I understood that where only a single ##any was used the non-determinism would only be in the case of a choice group and not a sequence group. The reason that I included running Xerces examples of the use of the minor version extension proposal was to show there were no problems with the declarations I've proposed. Could you please illustrate the problem you see with the declarations I've proposed by using a W3C Schema processor and the examples I've given? Perhaps I've missed a user requirement for minor versions that was not brought to my attention. Thank you, Bryan, for your post ... but from what I can tell the concerns that have come to light in your analysis may, indeed, not be concerns based on actual tests engaged with available processors. I illustrated the working use of u:FutureVersions in my paper with a concrete example that, fortunately, did not trip any of the problems that you postulated. The problem that came to light in last night's meeting was one of philosophical use of the future version area and the abuse it opens up by users not following the guidelines. I'm not aware of any technical obstacles to my proposal (otherwise I would not have suggested what I did and supported it with a working example). I'm hoping that someone will be able to improve on my suggestions with demonstrative illustrations of precisely the code we need to meet the user requirements ... there is no time remaining to talk about these issues only in prose. . . . . . . . . . . . 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]