[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SV: [ubl] Extension Element Action item SV: [ubl] Minutes of Atla ntic UBL TC call 5 April 2006
Hi Mike If we do not allow new attributes then we may need to define a ABIE that contains the (XSD:Any). Michael: In the PSC we would like to add an attribute called Context and an attribute called Subset to alle DocumentTypes. Does the rule about not to define new attributes also imply the we can't do this? Kind Regards Peter -----Oprindelig meddelelse----- Fra: Grimley Michael J NPRI [mailto:GrimleyMJ@Npt.NUWC.Navy.Mil] Sendt: 26. april 2006 16:28 Til: ubl@lists.oasis-open.org Emne: RE: [ubl] Extension Element Action item SV: [ubl] Minutes of Atla ntic UBL TC call 5 April 2006 All, How about two rules: [CTDx] The xsd:any element MAY only be used within the 'UBLExtension' element definition, and with xsd:processContents set to 'skip'. [ELD9] The 'UBLExtension' element MUST only be declared immediately following the 'UBLVersion' element within the document schema, with xsd:maxOccurs="1". <Bryan>"The attributes I propose are..."</Bryan> We currently do not allow attributes not defined by CCTS. Also, even those are only allowed on leaf nodes (BBIEs). I recommend capturing all this info in elements; let's try to minimize the 'damage'... Also, maybe these should be captured within the 'custom' element that will be a child of the 'UBLExtension' element. After all, this is information about *that* element, and not the 'UBLExtension' element. What do you think? Thanks, Mike -----Original Message----- From: Bryan Rasmussen [mailto:BRS@itst.dk] Sent: Tuesday, 25 April 2006 0714 To: ubl@lists.oasis-open.org Subject: [ubl] Extension Element Action item SV: [ubl] Minutes of Atlantic UBL TC call 5 April 2006 Hi, The following is what I figured could be the NDR text for xsd:any: 5.2.7 xsd:any Element UBL allows the use of xsd:any under controlled circumstances, because this feature permits the introduction of potentially unknown elements into an XML instance the processContents attribute of the element must always be set to skip as this will remove possible errors in the validation layer. The xsd:any construct is seen as aiding the requirements of interoperability and as mainly be useful in cases where organizations that wish to use UBL are required by law to send additional information not covered by the UBL document structure, thus extending the UBL message. Since it is a priority that there can be meaningful validation of the UBL document instances xsd:any must be used sparingly, and only within UBL defined elements meant for containing non-UBL elements that can be understood to extend UBL. Any use of xsd:any must also only allow no more than one element in the non-UBL namespace, this is to ease serialization of the extending element as its own XML instance that c an then be validated, if an implementer wishes to do so, outside the UBL validation process. [ELD9] The xsd:any element can be used, with processContents set to 'skip' and minOccurs=1, maxOccurs=1. ----------------------------------------------------------------------------- ----------------------------------------- The following is a very rough suggestion for how the element should actually look but Peter and I think it's a reasonable starting point to open up for discussion, it's taken from my original suggestions for how an Extension element should look, I suppose the name will be ExtensionPoint instead of ExtensibleContent: An ExtensibleContent area is an element in the understood format document that contains another format not related to the overall document format. The contents of the ExtensibleContent area can be further specified by those doing the extending via attributes on the element itself. The attributes I propose are ExtensionID - same semantics as schemeID extensionAgencyID - same semantics as schemeAgencyID for Extensions extensionAgencySchemeID - same semantics as schemeAgencySchemeID extensionAgencySchemeAgencyID - same semantics as schemeAgencySchemeAgencyID extensionReason - a codelist, I can think of a. Legal - the extension contains information required by in an area covering the extending body for documents of the type being sent. b. ReceiverRequested - the extension contains information that the receiver has requested be provided. c. ProvisionalTest - the extension is currently passing information that is being considered for inclusion into the next version of UBL, this would presume some sort of public repository of currently considered extensions. The sender is testing how the extension works in their system with trading partners. I'm not very wedded to this particular reason, as I'm not sure if it is something I would describe as a 'reason'. d. Application - the extension is a vendor specific extension mustUnderstand - a Boolean, only allowed in contexts of the extensionReason being legal, the sending party is claiming that in order for their document to be received validly the receiving party must understand it. I realize of course that this raises the spectre of balkanization again, but it seems to me that this would only be used when actually required by law, given that who in their right mind would send a document and require someone to understand it if it meant that by not understanding the receiving party could refuse it. extensionAgencyControllerID - in the context of the Danish UBL project the Danish Government ministry in charge of the technical wing of the project would be the Controller for any official extensions. extensionAgencyURI - a dereferenceable uri where information about the extension can be found. extensionDomain - the problem domain that the extender considers the extension to cover. Some evident domains - a. Presentation, handled via SVG, XHTML? b. Calculation, handled via MathML? Of course these are more evidently application extensions than semantics extensions. ExtensionDomainSchemeURI: a dereferenceable uri that will define the domain. ----------------------------------------------------------------------------- --------------------------------------------- Do these seem like reasonable attributes of such an area? Cheers, Bryan Rasmussen -----Oprindelig meddelelse----- Fra: Bryan Rasmussen Sendt: 20. april 2006 12:46 Til: 'Grimley Michael J NPRI' Cc: 'jon.bosak@sun.com' Emne: SV: [ubl] Extension Element Action item SV: [ubl] Minutes of Atlantic UBL TC call 5 April 2006 Hi Mike, Here is my stab at what the NDR should say for allowing xsd:any: 5.2.7 XSD:Any Element UBL allows the use of xsd:any under controlled circumstances, because this feature permits the introduction of potentially unknown elements into an XML instance the processContents attribute of the element must always be set to skip as this will remove possible errors in the validation layer. The xsd:any construct is seen as aiding the requirements of interoperability and as mainly be useful in cases where organizations that wish to use UBL are required by law to send additional information not covered by the UBL document structure, thus extending the UBL message. Since it is a priority that there can be meaningful validation of the UBL document instances xsd:any must be used sparingly, and only within UBL defined elements meant for containing non-UBL elements that can be understood to extend UBL. Any use of xsd:any must also only allow no more than one element in the non-UBL namespace, this is to ease serialization of the extending element as its own XML instance that can then be validated, if an implementer wishes to do so, outside the UBL validation process. [ELD9] The xsd:any element can be used, with processContents set to 'skip' and minOccurs=1, maxOccurs=1. I've cc'ed Jon but haven't posted to the list yet. Seem reasonable for the NDR requirements? Cheers, Bryan Rasmussen -----Oprindelig meddelelse----- Fra: Bryan Rasmussen [mailto:BRS@itst.dk] Sendt: 19. april 2006 12:46 Til: jon.bosak@sun.com; ubl@lists.oasis-open.org Emne: [ubl] Extension Element Action item SV: [ubl] Minutes of Atlantic UBL TC call 5 April 2006 > AGREED that the document extension area should go at a high > level, but last in the schema. > ACTION: PB and BR to submit a more detailed proposal along > these lines, possibly contacting MG offline; for submission > week after next at the latest. (Next week is the Easter > holiday in Europe.) Due to various issues around vacations and work schedules Peter and I haven't had an opportunity to talk together. It was my understanding that this Action Item was actually to be split into two, that is to say how should xsd:any be allowed in the Naming and Design Rules (which was the part that Mike Grimley volunteered to read over), and an item on how the element should look. Is this correct? I had planned on doing the NDR item over my vacation, but as it was a capoiera workshop where I ended up training 7+ hrs per day and dancing all night as part of the workshop's social obligations I ended up only being able to do about 3 hours of the work I'd intended to do over my vacation, and none of that was on the NDR (yet strangely, I am quite happy ). However I figure I can have the NDR part of the item later on this week, if that is in fact still part of the action item. Sorry for the inconvenience, Bryan Rasmussen --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]