Skip
repetitive navigational links
L-Soft  -  Home of  the  LISTSERV  mailing list  manager LISTSERV(R) 14.5
Skip repetitive navigational links
Previous messageNext messagePrevious in topicNext in topicPrevious by same authorNext by same authorPrevious page (December 2004)Back to main MODS pageJoin or leave MODSReplyPost a new messageSearchProportional fontNon-proportional fontLog in
Date:         Mon, 20 Dec 2004 11:16:49 -0500
Reply-To:     Metadata Object Description Schema List <[log in to unmask]>
Sender:       Metadata Object Description Schema List <[log in to unmask]>
From:         Andrew E Switala <[log in to unmask]>
Subject:      Re: RELAX NG vs. XML Schema, and alternative MADS suggestion
Comments: To: [log in to unmask]
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline

Actually, XML schema language can express constraints like that (a name authority must have only name variants with the same type attribute), but the technique is aesthetically...dubious. In English, you give each descriptor an attribute with a fixed value that defines its equivalence class (e.g. titles and name+title combinations might be variants of each other, likewise geographic and hierarchicalGeographic, so they're in the same class). Then use keys and keyrefs to enforce the constraint that descriptors in different equivalence classes can't appear in the same MADS record. Schema fragment: <xs:complexType name="madsType"> ... <xs:key name="eqclass-key"> <xs:selector xpath="mads:authority/*"/> <xs:field xpath="@eqclass"/> <xs:field xpath="@type"/> </xs:key> <xs:keyref name="same-eqclass" refer="mads:eqclass-key"> <xs:selector xpath="mads:variant/*"/> <xs:field xpath="@eqclass"/> <xs:field xpath="@type"/> </xs:keyref> </xs:complexType> <xs:complexType name="titleType"> ... <xs:attribute name="eqclass" fixed="titles"/> ... </xs:complexType> <xs:complexType name="nameTitleType"> ... <xs:attribute name="eqclass" fixed="titles"/> ... </xs:complexType> <xs:complexType name="titleType"> ... <xs:attribute name="eqclass" fixed="names"/> ... </xs:complexType> etc. >>> [log in to unmask] 12/17/04 7:18 PM >>> <snip> Not only does this make logical sense, it also allows one to much more finely-control validation. A person element thus cannot have an authorized name that is a corporate name, and an authorized name that is a person cannot have a variant that is a corporate name, or -- much worse -- a title.


Back to: Top of message | Previous page | Main MODS page

LISTSERV.LOC.GOV CataList email list search Powered by LISTSERV email list manager