[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: SV: SV: [ubl] Discussion XSD implementation of extensions
At 2006-07-13 15:37 +0200, Bryan Rasmussen wrote: >Allan just pointed out the UBL rule that one can't have an empty element, >i.e. element without content or attributes. > >With what you're proposing for Streaming purposes one ends up with possible >empty elements. Yes, but in the Atlantic meeting that you and Allan missed this was raised and the rule was changed to allow the extension element to be empty. Check out: http://www.oasis-open.org/committees/document.php?document_id=19124 and you will see ELD7 reads as follows: "Empty elements MUST not be declared, except in the case of extension, where the 'UBL Extension' element is used." Once the syntax of the UBL Extension element is finalized, we'll change the wording to reflect ext:ExtensionContent element name. >Fra: Bryan Rasmussen [mailto:BRS@itst.dk] >Sendt: 13. juli 2006 14:43 >Til: G. Ken Holman; ubl@lists.oasis-open.org >Emne: SV: SV: [ubl] Discussion XSD implementation of extensions >... >Don't know if it should be allowed to be empty, despite the benefits to >streaming processing. I don't want things to be done in a particular way to >benefit one processing model. But if you turn that argument around, it would be a shame to penalize a particular processing model by a modeling decision that would be acceptable either way to other processing models. >What do you think the chances are of people outputting extension elements >that are empty? Without extension content? In my proposed methodology, there is a 100% chance: http://www.oasis-open.org/committees/document.php?document_id=18849 In my processing model I posit that an application expecting either no extension or optional extension "X" will need to process an instance with an extension "Y" to remove the extension "Y" such that the end result can be validated with the schema that expects optional extension "X". It was in this discussion paper where I was justifying the necessity to remove extension namespace elements from instances and still have the end result validated against a schema, thus requiring the end result of intermediate processing to have empty content for that one element. What I really like now about your reminder for us to include extension metadata, is that even after removing the extension namespace from the instance, the processing application has enough information to know that there even was an extension in the instance before the instance was massaged. This might help direct workflow processes. With metadata my "X" application can now inspect its validated intermediate instance and see that there was a "Y" extension present in the original instance, but it is dealing with a pure "X" set of information items. >Also I would think that would make it difficult or less optimizable for some >implementors that might want different handling of extensions or not >stream-based handling of the format. I'm sorry I don't understand what you mean by that. Tree-based processing can inspect the presence of the extension easily, while stream-based processing cannot inspect the presence of the extension without waiting until it encounters the extension ... or have labourious look-ahead issues that could impact performance and maintenance. But I hope I have convinced you of the accommodation of an instance with unexpected extensions removed to still be allowed to be validated with a schema before application processing. I used the arguments above in the Atlantic call, and I feel strongly after an analysis of the impact of system design that removing the look-ahead issue for stream processing should be regarded as removing an obstacle to deployment, rather than regarded as adding a preferential bias of any kind. After all, tree-based processing doesn't need to worry about look-ahead, so let's accommodate stream-based processing if we can easily. Please let me know if this hasn't convinced you. . . . . . . . . . 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]