Hi Helen, The XML Schema design pattern that allows you to import a "common" schema and have it inherit the namespace of the schema that imports it is sometimes called a "Chameleon" namespace design.
This is achieved by placing the "common" schema in the empty namespace, and using the following method to import it into another schema and apply a namespace to it: <xs:include schemaLocation="common.xsd"/> There is a good write-up of it here: http://www.xfront.com/ZeroOneOrManyNamespaces.html#mixed Thanks. -jb On Wed, Jul 13, 2011 at 12:00 PM, helen chen <[email protected]> wrote: > Hi Geert, > > I played a little bit, I created a common schema with type PhoneNumber > in namespace "http://www.aa.com/datamodel/common"; , and then a > contactInfo schema in namespace "http://www.aa.com/datamodel/account"; > which imports the common schema. The schema is as following: > > common schema: > > <?xml version="1.0" encoding="UTF-8"?> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; > xmlns:tns="http://www.aa.com/datamodel/common"; > targetNamespace="http://www.aa.com/datamodel/common"; > elementFormDefault="qualified" attributeFormDefault="qualified"> > <xs:annotation> > <xs:documentation>This scheme defines common shared data object > types.</xs:documentation> > </xs:annotation> > <xs:complexType name="PhoneNumber"> > <xs:sequence> > <xs:element name="countryCode" type="xs:string" > minOccurs="0" > maxOccurs="1"/> > <xs:element name="areaCode" type="xs:string" > minOccurs="0" maxOccurs="1"/> > <xs:element name="exchange" type="xs:string" > minOccurs="0" maxOccurs="1"/> > <xs:element name="number" type="xs:string" > minOccurs="0" maxOccurs="1"/> > <xs:element name="extension" type="xs:string" > minOccurs="0" maxOccurs="1"/> > </xs:sequence> > </xs:complexType> > </xs:schema> > > > then the contactInfo schema like following: > <?xml version="1.0" encoding="UTF-8"?> > <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; > xmlns:tns="http://www.aa.com/datamodel/account"; > xmlns:data-common="http://www.aa.com/datamodel/common"; > targetNamespace="http://www.aa.com/datamodel/account"; > elementFormDefault="qualified" attributeFormDefault="qualified"> > <xs:annotation> > <xs:documentation>This schema defines data object types used > for > interfaces</xs:documentation> > </xs:annotation> > <xs:import namespace="http://www.aa.com/datamodel/common"; > schemaLocation="common.xsd"/> > <xs:element name="contactInfo" type="tns:ContactInfo"/> > <xs:complexType name="ContactInfo"> > <xs:sequence> > <xs:element name="phone" type="data-common:PhoneNumber" > minOccurs="0"/> > </xs:sequence> > </xs:complexType> > </xs:schema> > > > Then I used XMLspy to create sample xml based on contactInfo schema: > > <?xml version="1.0" encoding="UTF-8"?> > <tns:contactInfo > xsi:schemaLocation="http://www.aa.com/datamodel/account > accountContact.xsd" xmlns:tns="http://www.aa.com/datamodel/account"; > xmlns:data-common="http://www.aa.com/datamodel/common"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";> > <tns:phone> > <data-common:countryCode>String</data-common:countryCode> > <data-common:areaCode>String</data-common:areaCode> > <data-common:exchange>String</data-common:exchange> > <data-common:number>String</data-common:number> > <data-common:extension>String</data-common:extension> > </tns:phone> > </tns:contactInfo> > > > you can see for contactInfo, the element phone is in the same > namespace of contactinfo, but all the child elements inside phone are > in common namespace. > > This result is not what I want. I think usually I would prefer the > element phone and all its' children are in the same namespace (like > common). > > Did I miss anything here? > > Thanks, Helen > > > > On Wed, Jul 13, 2011 at 2:56 AM, Geert Josten <[email protected]> > wrote: >> Hi Helen, >> >> I'd recommend to make a shared schema file (more or less your option 2) that >> contains complex types for things like address and person. When defining an >> editor, you simply say that the type of that element is that of the complex >> type person. That way editor will be in its own namespace, but person as >> type still shareable.. >> >> HTH >> >> Kind regards, >> Geert >> >> -----Oorspronkelijk bericht----- >> Van: [email protected] >> [mailto:[email protected]] Namens helen chen >> Verzonden: dinsdag 12 juli 2011 21:48 >> Aan: [email protected] >> Onderwerp: [MarkLogic Dev General] question about organizing schema >> >> Hello there, >> >> I'm learning xml schema, and I have a question that somewhat confuses me. >> >> if I have a structure like the following: >> >> person >> profile >> firstname >> lastname >> title >> address >> street >> city >> state >> zip >> >> in Marklogic, if I have element editor and author, and I want to >> distinguish them in different namespace so when I do search by name, I >> won't mix editor's name and author's name. >> >> I can have two ways to design the schema: >> >> 1. when I design the schema, I would put editor into one schema with >> one namespace, and put author into another schema with another >> namespace. this way inside document editor and author are seperated by >> namespace. This way can fit the marklogic search. >> >> 2. just by looking at the structure, I'm very easily to think about >> putting profile and address into a common schema with namespace like >> "common-ns". and then another schema for person, which will import the >> the common schema to reuse the profile element and address element. >> but the person schema usually will be in another namespace. I have >> this thinking is because I do java a lot and this way seems to make >> element reusable. >> but the problem for this approach is: since editor and author are >> all type of person, and person will import common schema, so all the >> profiles for editor and author will be in same namespace, then in >> marklogic I won't be able to distinguish them and cannot do search. >> >> Maybe I mixed the schema design with Marklogic. I'm kind of new to >> schema design, and to me both way seems to have their purpose. >> >> I'm wondering in general when designing schema, do we make reusable >> element in a common schema? if so, then what is best/common way for >> using namespace in schema? >> >> Or in this case, what is the common way to design the schema? Does the >> common way schema design always fit Marklogic? >> >> One idea pops up to me is: maybe Marklogic is for data manipulate, so >> we have one schema for marklogic, and then another schema to be used >> for public. >> >> I hope to get some help on this topic, or maybe point me to some >> articles that describe the common sense of schema design. >> >> Thanks a lot, >> Helen >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general >> _______________________________________________ >> General mailing list >> [email protected] >> http://developer.marklogic.com/mailman/listinfo/general >> > _______________________________________________ > General mailing list > [email protected] > http://developer.marklogic.com/mailman/listinfo/general > _______________________________________________ General mailing list [email protected] http://developer.marklogic.com/mailman/listinfo/general
