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: [ubl] Two essential items for Atlantic call


Hi,

>>   UBLExtensionType:

>I had originally thought it would look something like this:
>
>        <xsd:complexType name="UBLExtensionType">
>        	<xsd:sequence>
>		<xsd:any namespace="##any" processContents="skip"
minOccurs="1" maxOccurs="unbounded"/>
>        	</xsd:sequence>
>        </xsd:complexType>

I think there was miscommunication between various parties. Some people
wanted it with metadata as to the extension reason. I suggested using
attributes on the element but it was pointed out we couldn't have new
attributes.

Then in the Brussels meeting Stephen and I tried to specify the metadata as
to the reason of an extension as a seperate element, a sibling of the
extension. I suppose this was changed giving what you show below:

><xsd:complexType name="UBLExtensionType">
>    <xsd:sequence>
>        <xsd:element ref="cbc:ID" minOccurs="0" maxOccurs="1">
>        <xsd:element ref="cbc:Name" minOccurs="0" maxOccurs="1">
>        <xsd:element ref="cbc:AgencyID " minOccurs="0" maxOccurs="1">
>        <xsd:element ref="cbc:AgencyName" minOccurs="0" maxOccurs="1">
>        <xsd:element ref="cbc:VersionID" minOccurs="0" maxOccurs="1">
>        <xsd:element ref="cbc:AgencyURI" minOccurs="0" maxOccurs="1">
>        <xsd:element ref="cbc:URI" minOccurs="0" maxOccurs="1">
>        <xsd:element ref="cbc:ExtensionReasonCode" minOccurs="1"
maxOccurs="1">
>        <xsd:element ref="cbc:ExtensionReason" minOccurs="0" maxOccurs="1">
>        <xsd:element ref="cbc:ExtensionContentAny" minOccurs="1"
maxOccurs="1">
>    </xsd:sequence>
></xsd:complexType>


>    - One might argue that all of these elements (except for
'ExtensionContent') are properties of the ''ExtensionContent'
>element, *not* the 'UBLExtension' element.

Then you would have something like

<xsd:complexType name="ExtensionContentAnyType">
    <xsd:sequence>
        <xsd:element ref="cbc:ID" minOccurs="0" maxOccurs="1">
        <xsd:element ref="cbc:Name" minOccurs="0" maxOccurs="1">
        <xsd:element ref="cbc:AgencyID " minOccurs="0" maxOccurs="1">
        <xsd:element ref="cbc:AgencyName" minOccurs="0" maxOccurs="1">
        <xsd:element ref="cbc:VersionID" minOccurs="0" maxOccurs="1">
        <xsd:element ref="cbc:AgencyURI" minOccurs="0" maxOccurs="1">
        <xsd:element ref="cbc:URI" minOccurs="0" maxOccurs="1">
        <xsd:element ref="cbc:ExtensionReasonCode" minOccurs="1"
maxOccurs="1">
        <xsd:element ref="cbc:ExtensionReason" minOccurs="0" maxOccurs="1">
        <xsd:any namespace="##any" processContents="skip" minOccurs="1"
maxOccurs="unbounded"/>
    </xsd:sequence>
</xsd:complexType>

Yes, but if they were inside of the ExtensionContentAny then that would be
non-deterministic. 

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 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. Not seperating the extending content from the real content also
forces implementers to worry about generic queries on the xml structure. 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.
Obviously implementors can deal with this, but I like to keep development
possibilities as open as possible for as long as possible. 

Cheers,
Bryan Rasmussen




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