[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Alternate schema
<?xml version="1.0" encoding="ISO-8859-1"?> <xs:schema targetNamespace="http://xdi.oasis-open.org" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema" > <!-- Proposed changes --> <!-- 1. Schema extensibility The schema design pattern used is also sometimes referred to as Salami Slice, because each type is a 'slice' thats put together using ref attributes. This design pattern balances size and extensibility, but given the limited number of element types, why not go for full extensibility and use the venetian blind model, where each component is a type. --> <!-- 2. Comment element The comment annotation says it is only for human readable annotations and is completely ignored by XDI processors. If that's the case then what is the value of xdi:comment over xml comments? --> <!-- 3. There seems to be two types of data elements, one that is XDI data, and one that is non-XDI data. To that end I'd propose reflecting this difference in the schema with the addition of a XDIdata element. --> <!-- 4. All of the XDI elements (except for comment) are XRI addressable as I understood from discussions, but in the schema not all of them are. We can make this clearer by having an abstract type addressable and having addressable type extend it. I also had two other ideas relating to the addressing. The first is that it might be desirable to allow alternate forms of addressing to be represented as well, and so I've added an <addresses> element which can contain <xri> elements, and other non xdi elements. The other idea is that an address itself could, and probably often would be, a resource, so I added that possibility into <address>. There should however be at least one XDI address, so I've specified a mandatory xri or resource at the beginning of the addresses. This then becomes the primary address. While in theory the beauty of having resources under address is attractive, I am not fully convinced the benefits outweigh storing statements about the address itself within the XDIattributes tree. I'm also not sure how you would address such resources..you have * for resources under XDIattributes, / for resources under XDIdata, but for resources under addresses? --> <!-- 5. xri as string. I strongly agree with adding a pattern restriction, but it needs to be created by someone who knows more than myself about XRI. --> <!-- 6. After the above changes we'd have possible child elements within resource of (a) 1*addresses: which could be a container for resources (b) Either 1*data: really the leaf of the XDI tree or 1*XDIdata: a container for resources (c) n*resources It may just be my love of symmetry, but it seems that it might be useful for both readability and parsing if we have resource container element for child resources of a resource element. Based on the discussions of path navigation one candidate pops immediately to mind, <attributes>. Changing the name to match XDIdata we have XDIattributes --> <xs:simpleType name="xri"> <xs:restriction base="string"> <xs:annotation> <xs:documentation> This element definition may be enhanced to include an XML pattern element matching the XRI ABNF, so a standard XML schema validating parser will be able to validate that an XRI value is legal. </xs:documentation> </xs:annotation> </xs:restriction> </xs:simpleType> <xs:complexType name="addresses"> <xs:sequence> <xs:choice minOccurs="1" > <xs:element name="xri" type="xri" /> <xs:element name="resource" type="resource" /> </xs:choice> <xs:choice minOccurs="0" maxOccurs="unbounded" > <xs:element name="xri" type="xri" /> <xs:element name="resource" type="resource" /> <xs:any namespace="##other" processContents="strict" /> <xs:any namespace="##local" processContents="strict" /> </xs:choice> </xs:sequence> </xs:complexType> <xs:complexType name="addressable" abstract="true"> <xs:sequence> <xs:element name="addresses" type="addresses" minOccurs="1" maxOccurs="1"/> </xs:sequence> </xs:complexType> <xs:complexType mixed="true" name="data"> <xs:complexContent> <xs:extension base="addressable"> <xs:choice minOccurs="0" maxOccurs="unbounded" > <xs:any namespace="##other" processContents="strict" /> <xs:any namespace="##local" processContents="strict" /> </xs:choice> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="XDIdata"> <xs:complexContent> <xs:extension base="addressable"> <xs:sequence> <xs:element name="resource" type="resource" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="XDIattributes"> <xs:complexContent> <xs:extension base="addressable"> <xs:sequence> <xs:element name="resource" type="resource" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="resource"> <xs:complexContent> <xs:extension base="addressable"> <xs:sequence> <!-- allow XDIdata or data, but not both --> <xs:choice minOccurs="0"> <xs:element name="data" type="data" /> <xs:element name="XDIdata" type="XDIdata" /> </xs:choice> <!-- allow any element except those from target namespace --> <xs:choice minOccurs="0" maxOccurs="unbounded" > <xs:any namespace="##other" processContents="strict" /> <xs:any namespace="##local" processContents="strict" /> </xs:choice> <xs:element name="XDIattributes" type="XDIattributes" minOccurs="0" /> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:schema>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]