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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ssc message

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


Subject: Re minor version Schema design


Greetings SSC

Re minor version Schema design
----------------------------------------

I've been looking through the ATG2 NDR and the UBL NDR
and thinking about the options available to us, as discussed,
and it seems to me we'd best do the following:

**********************************************

Redeclare all elements and complexTypes for 1.1 BIEs and 
avoid extension (just add a new BBIE, say, to the end of
an ABIE's redeclaration) as in ATG2's NDR and not use
restriction except to create a new BIE (with a new name)
from another - again as in ATG2's NDR. 

**********************************************

[Reasons:

Tony has pointed out the need to redeclare everything
to give each BIE the new namespace and allow reuse
in the following minor version (without having to import
every single previous version to avoid having to declare 
too many multiple namespaces in an instance)

I have shown that we cannot have a non-derived ABIE
which is associated with a derived BIE, which very much 
limits import/derivation use

David has pointed out the variation on the relevant rules
in the ATG2 NDR where *for BIEs* extension is avoided 
and restriction is limited to renamed BIEs only.

A key advantage is that the instances would only 
need new namespaces without the need for a different
textual structure or extra prefixes here and there.]


Do others in SSC agree with this design? If so we'd need 
to get feedback on this from NDR Team/TC and fairly 
certainly have extra NDRules produced to eliminate
the human choices in the design.

All the best

Steve



>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 18/03/05 15:14:03 >>>
Amendment: I think, for extension, the
redeclared InvoiceLineType would need an extra
intermediate name since it would otherwise
appear twice in the same namespace.
This might then need a new Naming and Design Rule
for the intermediate complexType name.

[original message is at
  http://lists.oasis-open.org/archives/ubl-ssc/200503/msg00013.html ]

>>> "Stephen Green" <stephen_green@bristol-city.gov.uk> 03/18/05 13:05 PM >>>

...    possibly here a redeclaration of the 1.0 elements and global complexTypes under the 1.1 namespace  ...

	<xsd:element name="InvoiceLine" type="InvoiceLineType"/>
	...
               redeclaration of the InvoiceLineType
               ...
               <!--  extension of InvoiceLineType -->
               <xsd:complexType name="InvoiceLineType">
		<xsd:complexContent>
			<xsd:extension base="InvoiceLineType">
				<xsd:sequence>
					<xsd:element ref="cbc:InspectionDate" minOccurs="0"/>
				</xsd:sequence>
			</xsd:extension>
		</xsd:complexContent>
	</xsd:complexType>

... further redeclarations of the 1.0 elements and global complexTypes under the 1.1 namespace  ...






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