RE: Response to LC-75 XML Schema Issue

	Thank you for the follow-up. I do consider Henry's explanation an
adequate answer to my question.

	It has always been my hope for XSchema that XSchema would be at
least as powerful as SQL in terms of schema definition. The driving forces
behind XSchema go back to the need to represent 'data centric' documents,
which must eventually tie into database structures at one end and (object)
programming language structures at the other. I think the datatyping and
type extesibility of XSchema are powerful enough to satisfy both ends.
However, I think XSchema does not go far enough in the area of constraint
definition. Even if XSchema does not want to include an entire computational
expression language and operator definition language, I think it could have
an explicit recognition of the need for further constraint processing.
	I realise that from a language design perspective, giving people a
'constraint hook' and allowing implementation of constraints to be done in
any language at all leads to all sorts of nasty problems involving the
availability of XSL/Java/JScript/VB processors to run the constraint
processing, and you therefore begin down the slippery slope towards putting
it all in your own language in order to guarantee uniformity and
availability. I for one would welcome the expansion of XSchema to include
constraint (and therefore extensible operator definition) language
facilities. Additionally, the organisation of domain, key, integrity and
other constraints into a consistent system may allow for the creation of a
controllable enforcement specification - context sensitive validation of
documents such as was discussed by Allan Brown of Microsoft at XML Europe
2000. As an example of such a need, the same financial information sent to
two different investors is constrained in content and completeness by the
sophistication of the investor (under US securities laws). It would be nice
to be able to state the constraint and the control protocol declaratively
within the schema.
Thank you again,
David vun Kannon

> -----Original Message-----
> From: Frank Olken [mailto:olken@lbl.gov]
> Sent: Thursday, September 28, 2000 8:43 PM
> To: dvunkannon@kpmg.com; 'www-xml-schema-comments@w3.org'
> Subject: Response to LC-75 XML Schema Issue
> 
> 
> Dear David Vun Kannon:
> 
> The XML Schema Working Group has spent the last several months
> working through the comments received from the public on the last-call
> draft of the XML Schema specification.  We thank you for the comments
> you made on our specification during our last-call comment period, and
> want to make sure you know that all comments received during the
> last-call comment period have been recorded in our last-call issues
> list (http://www.w3.org/2000/05/12-xmlschema-lcissues).
> 
> Among other issues, you raised the point registered as issue
> LC-75. appinfo: Using appinfo annotations to store integrity 
> constraints
> 
> Henry Thompson responded earlier to your comments and you 
> acknowledged receipt, but we are unclear whether you considered
> the response to be adequate.
> 
> Please review the discussion below, and respond as to whether
> this resolution is satisfactory.
> 
> 
> 
> LC-75. appinfo: Using appinfo annotations to store integrity 
> constraints
> --------------------------------------------------------------
> -----------
> 
> Issue Class: A Locus: structures 4.3.10 Cluster: 09 appinfo 
> Status: unassigned
> Assigned to: Frank Olken Originator: David Vun Kannon
> 
> Description
> 
> Is it an appropriate use of appinfo annotations to use them to 
> store aplication-specific integrity constraints 
> (e.g. SQL CHECK constraints)?
> 
> Interactions and Input
> 
> Cf. XML Schema considered inadequately extensible
> Cf. Provide guidance on extending schema for schemas?
> 
> Input from Vun Kannon, David:
> -----------------------------
> 
> "Vun Kannon, David" <dvunkannon@kpmg.com> to XML Schema 
> Comments list, 
> Mon, 1 May 2000 16:28:00 -0400 
> 
> I am considering, as the subject line says, using appinfo annotations 
> to store integrity constraints. Consider a document as the transfer 
> syntax for a database predicate. An integrity constraint might be 
> "no worker earns more than their supervisor" or "pay_rate > 0". 
> These integrity constraints could be expressed as CHECK constraints in
> SQL, 
> for instance. 
> 
> I was considering trying to achieve the same effect with XSL-T 
> templates in appinfo elements. Unfortunately, it appears that 
> even in the April 7 draft, annotation and appinfo are poorly 
> documented. 
> Annotation is used but not defined in either the schema for schemas 
> or DTD, and appinfo (and documentation) similarly. What is 
> the content 
> model ()+ supposed to mean, in sec 4.3.10? 
> 
> Your comments appreciated on the appropriateness of the idea, 
> and my understanding of appinfo. 
> 
> 
> Input from Henry Thompson:
> --------------------------
> ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 
> 01 May 2000 21:46:13 +0100
> 
> "Vun Kannon, David" <dvunkannon@kpmg.com> writes: 
> 
> I am considering, as the subject line says, using appinfo annotations 
> to store integrity constraints. Consider a document as the 
> transfer syntax for a database predicate. An integrity constraint 
> might be "no worker earns more than their supervisor" or 
> "pay_rate > 0". 
> These integrity constraints could be expressed as CHECK constraints 
> in SQL, for instance. 
> 
> 
> That's exactly the sort of thing appinfo is designed for. 
> Sorry the documentation is less complete in this area than it 
> should be. 
> As the schema for schemas reveals, the content model for appinfo 
> is constrained only in so far as it may not contain elements from 
> the XML Schema namespace itself -- anything else, in any combination, 
> is fine. 
> 
> So declare a namespace at the top of your schema, and put whatever 
> you like from that namespace inside appinfo. If you give your schema 
> validator a schema for that namespace as well as the schema 
> for schemas, 
> the contents of appinfo from that namespace will get schema-validated 
> as well. 
> 
> Input from Vun Kannon, David:
> -----------------------------
> "Vun Kannon, David" <dvunkannon@kpmg.com> to XML Schema 
> Comments list, 
> Wed, 3 May 2000 11:53:02 -0400 
> 
> Got it. 
> 
> 
> 
> Is this response adequate ?
> ------------------------------
> 
> We (XML Schema Working Group) want to know your opinion
> of our response to your last call comments.  This information
> will be included with the package submitted to the W3C
> Executive Director as part of the recommendation to take
> the XML Schema Language to Candidate Recommendation.
> We would appreciate your response as soon as possible.
> 
> Please choose from one of the following responses, adding 
> whatever details, explanation you wish:
> 
> 1)  "Good enough"  - You are satisfied with the Schema WG response
> to your comments on XML Schema Language.  The response meets 
> your requirements.  The matter may be considered resolved.
> 
> 2) "Stop the presses"  - You are not happy with the response
> to your comments on XML Schema Language.  Either the response
> is unclear or inadequate.  The issue is of sufficient importance
> and urgency that you want it called to the attention of the 
> W3C Executive Director and you ask that the XML Schema Language 
> delayed in advancing to Candidate Recommendation until the 
> issue is resolved. 
> 
> 3)  "Later - Version 1.1"  - You are not happy with the response,
> but are prepared to defer reconsideration until XML Schema Lang.
> Version 1.1 is drafted.  It is anticipated (hoped) that Version 1.1
> will be completed by mid-2001.  Version 1.1 is intended primarily
> to fix small issues needed by other W3C Working Groups to proceed 
> with their work (especially XML Query Language).  You request that
> your comments be reconsidered when drafting the Version 1.1 
> requirements document.
> 
> 4) "Later - Version 2.0"  - You are not happy with the response,
> but are prepared to defer consideration until XML Schema Language
> Version 2.0 is drafted.  It is anticipated that Version 2.0 would
> not be completed until late 2001 or early 2002.  Version 2.0 may
> include major revisions, e.g., multiple inheritance, etc.
> You request that your comments be reconsidered when drafting the 
> Version 2.0 requirements document.
> 
> 5) "No longer care"  - You are not happy with the response, but
> no longer care to pursue the matter, because ....
> 
> 
> 
>                   Frank Olken
>                   XML Schema Language Working Group
> 
>   Lawrence Berkeley National Laboratory   (510) 486-5891 (voice)
>   Mailstop 50B-3238                       (510) 486-4004 (fax)
>   1 Cyclotron Road                        (510) 843-5145 (home)
>   Berkeley, CA 94720, USA                 (510) 442-7361 (pager)
> 
>   E-mail:  olken@lbl.gov
>   WWW:     http://www.lbl.gov/~olken/
> 
*****************************************************************************
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorized. 

If you are not the intended recipient, any disclosure, copying, distribution
or any action taken or omitted to be taken in reliance on it, is prohibited
and may be unlawful. When addressed to our clients any opinions or advice
contained in this email are subject to the terms and conditions expressed in
the governing KPMG client engagement letter.         
*****************************************************************************

Received on Friday, 29 September 2000 11:15:14 UTC