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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

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


Subject: [ubl-ndrsc] [Fwd: Straw Man on Namespaces, Schema Module Architecture,etc.]


I put the forwarded straw man together for my X12 group, and thought it
might be a worthwhile discussion piece/target for this group.  Please
note that Bill, Dave, and Gunther in particular may want to look at this
because it touches on topics that they have agreed to champion.

I think the attached files should come through OK.  If they don't, I'll
send them separately.

--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com



There are several issues and decisions which are dependent on each
other, and which therefore can not be decided independently.   Some of
these have to do with how namespaces are used, how schema files are
organized, whether elements are qualified or unqualified, use of
elements vs. types, etc.

Per my volunteering on last weeks technical/syntax call, I have put
together a straw man example that is one (of several) architectural
approach(es) for deciding these issues.

Here are the basic features:

  1. In schemas defining components to be used in other schemas (similar
     to header or include files), only types are defined.  No elements
     are defined.
  2. There is one core schema of common stuff used across all
     domains/contexts.  This is one physical file with a unique
     namespace.
  3. Each particular domain (or subcommittee, etc.), such as finance or
     insurance, has its own set of common stuff used within the domain.
     Each domain has a unique physical file with a unique namespace.
     Each of these does an xs:import of the common namespace.
  4. Domain particular business information entities are derived from
     the common BIEs (or core components) by type extension.
  5. There is one physical schema file with a unique namespace per
     business document.  These each do an xs:import of the domain and
     common namespaces.
  6. Except in the final business document schema, elements are only
     declared within types.  So, in effect there are no global elements.
  7. elementFormDefault in each schema is unqualified.  The result of
     this is that type references in the schemas are (must be?)
     qualified, but element names in instance documents are unqualified
     (except for the root element).

Advantages of this approach:

   * Modularity
   * Simplicity - There are no case-by-case decisions to make about when
     to declare and element vs. type, since everything reusable is a
     type.
   * Ease of extension - types can be extended, while elements can't
   * Persons dealing with instance documents don't need to be confused
     with different namespace prefixes.

Disadvantages:  I'm not sure, but I'm sure there are several.  Take your
shots and lets see where the holes are.

Issues (that I can think of right off):

  1. For points 2 and 3 above, I haven't researched or worked this
     through enough to know whether the common and domain stuff can be
     broken down into multiple physical files that all share the same
     namespace.  If they can be, are there any advantages to doing this?
  2. Point 5 - Does the final root instance schema document need a
     unique namespace?, or can it share the namespace as the rest of the
     domain?

Other discussion:  I have seen at least one example where this approach
was take to the extreme of a type being defined for the root element of
the root instance business document schema.  If this approach were
taken, extension/customization would be even easier.

Here are the example files for common schema components (defining a
party), procurement schema components (with party extended by adding
DUNSNumber), a purchaseOrder schema, and a purchaseOrder instance
document.  These are all valid under XML Spy 4.1


--
Michael C. Rawlins, Rawlins EC Consulting
www.rawlinsecconsulting.com

<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XML Spy v4.1 U (http://www.xmlspy.com) by Michael C. Rawlins (Rawlins EC Consulting) -->
<xs:schema targetNamespace="http://schemas.webeschemas.org/purchaseOrder" xmlns:purchaseOrder="http://schemas.webeschemas.org/purchaseOrder" xmlns:com="http://schemas.webeschemas.org/commonStuff" xmlns:pro="http://schemas.webeschemas.org/procurementStuff" 
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="unqualified" attributeFormDefault="unqualified">
	<xs:import namespace="http://schemas.webeschemas.org/commonStuff" schemaLocation="commonStuff.xsd"/>
	<xs:import namespace="http://schemas.webeschemas.org/procurementStuff" schemaLocation="procurementStuff.xsd"/>
	<xs:element name="purchaseOrder">
		<xs:annotation>
			<xs:documentation>Comment describing your root element</xs:documentation>
		</xs:annotation>
		<xs:complexType>
			<xs:sequence>
				<xs:element name="buyer" type="pro:partyType"/>
				<xs:element name="seller" type="pro:partyType"/>
			</xs:sequence>
		</xs:complexType>
	</xs:element>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XML Spy v4.1 U (http://www.xmlspy.com) by Michael C. Rawlins (Rawlins EC Consulting) -->
<xs:schema targetNamespace="http://schemas.webeschemas.org/procurementStuff" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:com="http://schemas.webeschemas.org/commonStuff" elementFormDefault="unqualified" attributeFormDefault="unqualified">
	<xs:import namespace="http://schemas.webeschemas.org/commonStuff" schemaLocation="commonStuff.xsd"/>
	<xs:complexType name="partyType">
		<xs:complexContent>
			<xs:extension base="com:partyType">
				<xs:sequence>
					<xs:element name="DUNSNumber" type="xs:string"/>
				</xs:sequence>
			</xs:extension>
		</xs:complexContent>
	</xs:complexType>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XML Spy v4.1 U (http://www.xmlspy.com) by Michael C. Rawlins (Rawlins EC Consulting) -->
<po:purchaseOrder xmlns:po="http://schemas.webeschemas.org/purchaseOrder" xmlns:com="http://schemas.webeschemas.org/commonStuff" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://schemas.webeschemas.org/purchaseOrder
E:\Work\xmlTest\purchaseOrder.xsd">
	<buyer>
		<name>Big Spender</name>
		<street>14 Highland Heights Pkwy</street>
		<city>Dallas</city>
		<state>TX</state>
		<zipCode>75200</zipCode>
		<DUNSNumber>123456789</DUNSNumber>
	</buyer>
	<seller>
		<name>Needless Markup</name>
		<street>One Main Place</street>
		<city>Dallas</city>
		<state>TX</state>
		<zipCode>75201</zipCode>
		<DUNSNumber>987654321</DUNSNumber>
	</seller>
</po:purchaseOrder>
<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XML Spy v4.1 U (http://www.xmlspy.com) by Michael C. Rawlins (Rawlins EC Consulting) -->
<xs:schema targetNamespace="http://schemas.webeschemas.org/commonStuff" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:common="http://schemas.webeschemas.org/commonStuff" elementFormDefault="unqualified" attributeFormDefault="unqualified">
	<xs:complexType name="partyType">
		<xs:sequence>
			<xs:element name="name" type="xs:string"/>
			<xs:element name="street" type="xs:string"/>
			<xs:element name="city" type="xs:string"/>
			<xs:element name="state" type="xs:string"/>
			<xs:element name="zipCode" type="xs:string"/>
		</xs:sequence>
	</xs:complexType>
</xs:schema>




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


Powered by eList eXpress LLC