OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[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.

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 

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.

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]