[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
- From: Mike Rawlins <mike@rawlinsecconsulting.com>
- To: xmldr <X12CTG3-XMLDR@alex.shiman.com>
- Date: Wed, 14 Nov 2001 14:52:25 -0600
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