SV: SV: [ubl] Two essential items for Atlantic call

["Bryan Rasmussen" <BRS@itst.dk>]

>But wouldn't the non-determinism disappear with encapsulation?

Yes

>As an aside I still prefer not to have the the content of
ExtensionContentAny
>(or whatever name is chosen for actually holding the extending elements) be
>unbounded.

>I cited in the call that it would be an expected 
>use case (I think) that a single instance will have multiple extensions.

I figure that is the case as well. but then there is a need to associate
metadata with multiple extensions (if this is agreeable to people). Basically
I would rather see multiple extension elements, than one extension element
with multiple children. 

>>I prefer only one child of the extension because I think it offers
>>the most flexible way for dealing with that content, as in serialize child
of
>>ExtensionContentAny as own XML, track it in conjunction with parent
document.
>>doing that with multiple children can create performance problems for some
>>technologies.

>Can you elaborate on this?  

>>Not seperating the extending content from the real content also
>>forces implementers to worry about generic queries on the xml structure.

>I disagree ... since XPath addressing is the 
>basis of most querying languages, there is no 
>impact by the number of extension children when 
>directly addressing the main body.

>>Thus
>>one cannot use xpath or other techology to get all //com:InvoiceLine
because
>>that would also get the lines possibly put somewhere under the Extension.

>But the use of "//" is recognized as bad practice 
>in XPath and XSLT, except in circumstances where 
>leaf-level constructs are being addressed.

I agree it is recognized as bad practice, but how common of a practice is it?
Can we expect that ERP implementors won't read the spec, not connect mentally
that the extension element can theoretically hold elements in the same
namespace as various UBL  constructs, do their implementation, be tight for
time, have a problem and slip in a // somewhere? 

This is the scenario that is in my head when I think of this kind of thing,
probably because I have had to deal with a lot of people complaining that
things were bad because of vendor X's implementation. 


>Obviously implementors can deal with this, but I like to keep development
>possibilities as open as possible for as long as possible.

>Back to encapsulation, though ... to get the 
>metadata you cite above associated with each 
>extension we would need something like:

   

>With the above encapsulation, Bryan, do you think 
>we will have any non-determinism issues?

It looks like it  <cbc:ExtensionReason>...
       <nes:InvoiceExtension>
         ...legacy invoice stuff...
       </nes:InvoiceExtension>

nes:InvoiceExtension is in #any right, that means you could just as easily
have 
<cbc:ExtensionReason> ..</cbc:ExtensionReason>
<cbc:ExtensionReason> ..</cbc:ExtensionReason>
and then the validator doesn't know which it should validate as, depending of
course on the cardinality of cbc:ExtensionReason....
As a general rule it just makes things easier (with XSD) to wrap xsd:any
usage in its own non-contaminated element.



>I feel very strongly that multiple extensions 
>ought to be allowed ... 

It would be preferable. 

shoot I was going to join the call. might be late now.

Cheers,
Bryan Rasmussen