[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SV: SV: [ubl] Discussion XSD implementation of extensions
Hi Ken, 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. Cheers, Bryan Rasmussen -----Oprindelig meddelelse----- 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 >In retrospect I'm really liking this suggestion, >Bryan, of a container element. And that's >improving the aesthetics for me too: consider >that with the extension element each and every >UBL-defined object has a UBL-defined >sibling. I'm in agreement with this. >So, I now recommend we make the ExtensionContent >element last child of the UBLExtension element >mandatory and allow it to be empty. 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. What do you think the chances are of people outputting extension elements that are empty? Without extension content? 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. Cheers, 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]