RE: key/keyref in XML Schema

Alexander:
 
Here is the sort of thing we were trying to do with key/keyref last summer.
I haven't tried anything like this with available schema processors recently
to see whether any of them have implemented key/keyref.

Here is a Job Description instance document (default namespace is SIL, "e:"
is Edist
namespace, "f:" is File namespace).  f:File has
equivalenceClass="sil:Resource",
e:EdistJobDesc has equivalenceClass="sil:JobDesc", e:EdistInvocation has
equivalenceClass="sil:Invocation", e:Attachment has
equivalenceClass="sil:Input".  In this example, the ResourceRef elements
must refer to f:File element whose Format child element has the value
"text/plain" or "text/xml":
 
      <e:EdistJobDesc id="jd001" e:job-owner="jslein">
         <f:File id="io001">
               <Accessibility><Online/></Accessibility>
               <Format>text/plain</Format>
               <Location> http://www.wrc.xerox.com/sample1.txt
<http://www.wrc.xerox.com/sample1.txt> </Location>
               <f:Owner>sauvain</f:Owner>
               <f:DocName>Sample plaintext Document</f:DocName>
               <f:FileName>sample1.txt</f:FileName>
               <f:AuthorizationKey>jslein/somepassword</f:AuthorizationKey>
         </f:File>
         <f:File id="io002">
               <Accessibility><Online/></Accessibility>
               <Format>text/xml</Format>
               <Location> http://www.wrc.xerox.com/sample2.xml
<http://www.wrc.xerox.com/sample2.xml> </Location>
               <f:Owner>sauvain</f:Owner>
               <f:DocName>Sample xml Document</f:DocName>
               <f:FileName>sample2.xml</f:FileName>
               <f:AuthorizationKey>jslein/somepassword</f:AuthorizationKey>
         </f:File>
         <e:EdistInvocation id="inv001">
               <InputResourceClasses>
                  <e:Attachment>
                     <ResourceRef>io001</ResourceRef>
                     <ResourceRef>io002</ResourceRef>
                  </e:Attachment>
               </InputResourceClasses>
               <e:recipients> fgoetz@crt.xerox.com
<mailto:fgoetz@crt.xerox.com>  srevankar@crt.xerox.com
<mailto:srevankar@crt.xerox.com> </e:recipients>
               <e:host>saturn.wrc.xerox.com</e:host>
               <e:subject>Test of Email Distribution</e:subject>
               <e:from> jslein@crt.xerox.com <mailto:jslein@crt.xerox.com>
</e:from>
               <e:content>This is a test.  There should be 2
attachments.</e:content>
         </e:EdistInvocation>
      </e:EdistJobDesc>
 
Here is an extract from the schema for the SIL namespace.  Here we are
defining default key/keyref constraints, but we hope that implementers of
extension namespaces will define stricter constraints that will provide more
effective enforcement of the desired semantics than these default
constraints do:
 
<!-- Capability Descriptions SHOULD define their own key / keyref in their
extensions
     of JobDesc, especially if they define multiple
     types of inputs or multiple types of outputs.  This will enable the XML
parser
     to enforce the right cross-references in the job description.
-->
<element name = "JobDesc" type="sil:JobDesc">
   <key name="ResourceKey">
      <selector>Resource</selector>
      <field>@id</field>
   </key>
   <keyref name="InputResourceRef" refer="ResourceKey">
      <selector>Invocation/InputResourceClasses/Input/ResourceRef</selector>
      <field>.</field>
   </keyref>
   <keyref name="OutputResourceRef" refer="ResourceKey">
 
<selector>Invocation/OutputResourceClasses/Output/ResourceRef</selector>
      <field>.</field>
   </keyref>
</element>
 
<complexType name="Input" content="elementOnly" abstract="true">
   <element ref="sil:ResourceRef" minOccurs="0" maxOccurs="unbounded"/>
</complexType>
<element name="ResourceRef" type="Name"/>
<complexType name="Output" content="elementOnly" abstract="true">
   <element ref="sil:ResourceRef" minOccurs="0" maxOccurs="unbounded"/>
</complexType>
 
Here is an extract from the schema for extension namespace Edist.  It does
define stricter constraints on the keyrefs:
 
<element name="EdistJobDesc" type="e:EdistJobDesc" equivClass="sil:JobDesc">
   <key name="AttachmentKey">
      <selector>f:File[sil:Format="text/plain" or
sil:Format="text/xml"]</selector>
      <field>@id</field>
   </key>
   <keyref name="AttachmentRef" refer="AttachmentKey">
 
<selector>e:EdistInvocation/sil:InputResourceClasses/e:Attachment/sil:Resour
ceRef</selector>
      <field>.</field>
   </keyref>
</element>

-----Original Message-----
From: Falk, Alexander [mailto:al@altova.com]
Sent: Wednesday, January 17, 2001 1:10 PM
To: 'jslein@crt.xerox.com'
Subject: RE: XML Spy Support



Dear beta tester, 

we have currently not implemented unique/key/keyref in XML Spy 3.5, because
this aspect of XML Schema is not being used by most of our customers and
beta testers so far.

Once the W3C advances XML Schema to Proposed Recommendation status and it
still includes these identity-constraints, we will certainly be supporting
this in XML Spy, but this process may take some time.

As a member of the W3C XML Schema Working Group, I would, however, like to
ask you for some help in this matter: 
the W3C XML Schema Working Group did not receive nearly enough feedback on
these aspects of XML Schema during the Candidate Recommendation Period to
judge if the identity-constraints currently available in the Candidate
Recommendation are suitable for schema authors and users.

It would, therefore, be very important for the XML Schema Working Group to
receive further feedback regarding the use of unique/key/keyref
identity-constraints from schema authors and users. If you are using these
aspects of XML Schema and consider them important for your work, please
submit an e-mail to

        www-xml-schema-comments@w3.org 

and describe your use-case and why you require such capabilities for your
schema work. If possible, please do also include a sample XML Schema with
your posting that will give the XML Schema Working Group additional
feedback. Also, please do indicate whether any enclosed schema may be used
as part of an upcoming conformance test suite.

This will help the XML Schema Working Group decide whether the current
identiy-constraint mechanism is being used or if there are problems involved
that may require this feature to be dropped from the language for the time
being.

Thank you, 

Alexander 

... Alexander Falk 
... President, CEO of Altova, Inc. - The XML Spy Company 
... Member of the W3C XML Schema Working Group 
... Member of the W3C Advisory Committee 

========================================================================= 
XML Spy 3.0  -  the first true Integrated Development Environment for XML 
Visit http://www.xmlspy.com/ <http://www.xmlspy.com/>  to download a free
30-day evaluation version 
========================================================================= 


-----Original Message----- 
From: jslein@crt.xerox.com [ mailto:jslein@crt.xerox.com
<mailto:jslein@crt.xerox.com> ] 
Sent: Wednesday, June 07, 2000 15:57 
To: support@xmlspy.com 
Subject: XML Spy Support 


Email address: jslein@crt.xerox.com 

Last name        - Slein 
First name       - Judith 
Title            - Member Research & Technology Staff 
Company          - Xerox 
Department       - XR&T 
Street           - 
Zip              - 
City             - 
State            - 
Country          - 
Phone            - 
Fax              - 
Computer brand   - 
Processor        - 
CPU speed        - 
Operating System - Windows NT 4.0 
RAM              - 96 meg 
Hard disk (MB)   - 
Product          - XML Spy 3.0 
Question         -  I suspect that you are not checking keyrefs when
validating XML against a schema.  Is this correct?  Do you plan to add
support for validation of keyrefs?  I want to use fairly complex XPath
expressions with qualified names and complex predicates.

Received on Friday, 19 January 2001 17:43:20 UTC