XML Schema Last Call Issue LC-136: Symbolic Constants

                                        October 4, 2000
Mr. Goldfarb,

        The XML Schema WG has been considering various issues
raised in last call. You raised the issue known to the Schema WG
as LC-136: Symbolic Constants. This message constitutes the
Schema WG response to your comment.

Please see the following discussion of the issue and
the Schema WG response. At the close of this email you will find
instructions on how to respond, indicating whether the Schema WG
response is satisfactory to you.


LC-136. constants: Symbolic constants
-------------------------------------

Issue Class: D Locus: both Cluster: 15 constants Status: resolved
Assigned to: Frank Olken Originator: Steven Goldfarb 

Description
-----------

Should XML Schema provide support for typed symbolic constants?

Interactions and Input
----------------------

Input from Steven Goldfarb <Steven.Goldfarb@cern.ch>:

Steven Goldfarb <Steven.Goldfarb@cern.ch> to XML Schema Comments list 
on Fri, 12 May 2000 14:17:02 -0700 

We would like to request a modification to the current working draft 
of the XML Schema, Working Draft 7 April 2000. Specifically, 
we are interested in the implementation of a mechanism for the 
usage of symbolic constants in XML Schema. 

Efforts have recently begun in the High Energy Physics community to 
use XML to describe the geometry of our detectors. Several languages
have
already been developed toward this aim and we have recently begun work 
toward merging our efforts into a standard. 

Our geometrical description of a detector involves the construction 
of a complex structure from simple components in an iterative manner. 
We create elementary solids and position instances of them in space. 
These actions require the entry of explicit values for the dimensions 
of the solids and the coordinates of the positions. 
In our current model, we store these values as attributes. 
This involves the entry of thousands of values to describe these
complex detectors, making it essential to avoid data repetition. 
Ideally, we would like to be able to define a symbolic constant 
in the XML implementation which could be referenced throughout 
the document. The constant therefore needs to have a type, a name, 
a value and possibly a unit. In our case, we would include the 
constant as an attribute or as element content. Most likely, 
this implies the need for a mechanism to differentiate between 
a symbol and plain text when referencing. 

To give an example for the XML implementation, we would like to 
be able to describe a piece of geometry like: 

<constant name="chamber_width" value="105.254" unit="mm" />
<constant name="chamber_length" value="210.508" unit="mm" />

<box name="Upper Chamber" X="$chamber_width" Y="$chamber_length" 
        Z="32" material="Lead" />
<box name="Lower Chamber" X="$chamber_width" Y="$chamber_length" 
        Z="14" material="Copper" /> 


In this example, the parser would replace the name of the symbol 
with the value of the symbol. It is important that this also support 
type checking, i.e. in the example above, the attributes X, Y and Z 
should all be defined as 'double'. We realise that this feature is not 
implemented for XML and we hope that this will be revised in the future. 
However, XML schema could benefit from this by facilitating the 
creation of default values. In the current XML Schema working draft, 
the default values must be typed explicitly, and cannot be a
reference to a previously defined constant. 

During the course of our discussions with other experts we found 
that the 'Express' language contains a similar mechanism to handle 
symbolic constants, as well as being able to use arithmetic
expresssions. 
Clearly, also this community would benefit from our request. 

Resolution by Schema WG:
------------------------

Discussed in call of 2000-06-29.
[Editorial note: only W3C members have access to the archives. However,
I have included the most relevant messages. ] 

Several positions could be distinguished (not mutually exclusive): 

        1) we should add the constructs requested

        2) entities can be used to get the essential function, as
described by 
        MSM in
(http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2000Jun/0209 )
        (see included message below)

        3) union types (as proposed) can be used to get the essential
function, 
        as proposed by Curt Arnold in
        
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000AprJun/0372
        4) identity constraints can be used to get the essential
function, 
        as described by Dan Connolly (orally)
        [Editor's note:  I have no idea what is referred to here.]

        5) regardless of whether the essential functionality can be
achieved, 
        this is not functionality we should look to support in version
1.0.

A straw poll showed little support for adding the constructs, 
and substantial support for the view that this is not functionality
essential 
for XML Schema 1.0. The various workarounds had varying degrees of
support: 
most for entities, a lot for union construction, and some for 
identity constraints. 

RESOLVED:
---------
To dispose of issue LC-136 by saying no, mentioning the various partial 
or possible workarounds suggested, and saying this does not seem to be
functionality essential to version 1.0. 


Entity-based Workaround
------------------------

[Editor's note:  entities specified in DTD's are resolved 
before the schema processor commences its processing of the
infoset.]

Message-Id: <4.1.20000627125716.02068ac0@tigger.cc.uic.edu>
Date: Tue, 27 Jun 2000 13:11:26 -0600
To: w3c-xml-schema-ig@w3.org
From: "C. M. Sperberg-McQueen" <cmsmcq@acm.org>
Subject: LC-136 Symbolic constants

Issue LC-136 suggests that XML Schema provide a facility for defining,
and a syntax for referring to, symbolic constants.  The definitions
should give each constant a name, a type, a value, and optionally a
unit of measure.

The arguments in favor appear to be straightforward: whenever complex
information structures are written down and maintained, it is useful
to be able to use symbolic constants.  This makes the encoded
information clearer, it helps reduce the chances of error and increase
the chances that errors will be detected, and it simplifies
maintenance when the constants change.  Every high-level programming
language has them, Express has them, XML Schema should have them.

The arguments against would appear to be that this is just a shade too
complicated for version 1 (not all *early* high-level languages had
constants!), because it would require more design than we have time
for and offer more opportunities to make design errors than we can
afford.

There is also a rather closer similarity between the named constants
and XML entities than is wholly comfortable.  It's close enough that
one might imagine using entities instead of the proposed named
constants: the commentators' example would then read

 <!ENTITY chamber_width  "105.254"> <!-- constant, unit="mm" -->
 <!ENTITY chamber_length "210.508"> <!-- constant, unit="mm" -->
 ...
 <box name="Upper Chamber" 
      X="&chamber_width;" 
      Y="&chamber_length;" 
      Z="32"
      material="Lead" />
 <box name="Lower Chamber" 
      X="&chamber_width;" 
      Y="&chamber_length;" 
      Z="14" 
      material="Copper" /> 

This loses the schema-level knowledge of the names, and the
association of the names with the type and measurement unit; the type
information, however, attaches to the places where the constant is
used, in any case.  

Speaking as an individual, I would like to support this function
if we can; I'm not sure whether it's right for 1.0 or not.

Speaking as a chair, I am not sure whether the WG will adopt this
proposal or not, but I am confident that the WG does not NOW have
consensus in favor of the proposal.  Anyone who wishes to make
the case in favor of this proposal should start now, before LC-136
comes up in our meeting on Thursday.

-CMSMcQ


Union-type based Workaround
---------------------------

[Editor's note:  in the included message below "conjunction-type"
refers to "union-types", i.e., should be "disjunctive-type"]

Message-ID: <B2C1451A181BD411B88A00E018C1C19C08A683@THOR>
From: "Arnold, Curt" <Curt.Arnold@hyprotech.com>
To: "'Steven.Goldfarb@cern.ch'" <Steven.Goldfarb@cern.ch>, 
"'olken@lbl.gov'" <olken@lbl.gov>, "'marting@develop.com'"
<marting@develop.com>
Cc: "'www-xml-schema-comments@w3.org'" <www-xml-schema-comments@w3.org>
Date: Wed, 21 Jun 2000 12:52:54 -0600
Subject: LC-136: symbolic constants

Re: http://www.w3.org/2000/05/12-xmlschema-lcissues.xml#constants

I think the actual resolution of the symbolic constants is outside 
what you could expect from a generic XML processor, 
however a resolution of LC-2 conjunction types
(http://www.w3.org/2000/05/12-xmlschema-lcissues.xml#conjunction-types) 
and/or open enumerations 
(http://lists.w3.org/Archives/Public/www-xml-schema-comments/1999OctDec/0022.html
and
http://lists.w3.org/Archives/Public/www-xml-schema-comments/1999OctDec/0023.html)
might enable the behavior that you desire.


For example, using conjunction types:

<xsd:schema ...>
        <xsd:simpleType name="length" base="double">
                <xsd:annotation>
                        <xsd:documentation>Length in
meters</xsd:documentation>
                </xsd:annotation>
        </xsd:simpleType>
        <xsd:simpleType name="expression" base="string">
                <xsd:pattern value="$.*"/>
        </xsd:simpleType>
        <xsd:simpleType name="lengthExpr" base="string">
                <xsd:or>
                        <xsd:conform type="myschema:length"/>
                        <xsd:comform base="myschema:expression"/>
                </xsd:or>
        </xsd:simpleType>

        <xsd:element name="box">
                <xsd:complexType>
                        <xsd:attribute name="X"
type="myschema:lengthExpr"/>
                </xsd:compleType>
                ...
        </xsd:element>
        ...
</xsd:schema>

This would allow the X attribute of box to be either a double
interpreted 
as length in meters or a string starting with a $ that would be 
interpreted as an expression that would have to be resolved by
the application.

Open enumerations (which is referenced in LC-191 and I think is 
worthy of its own issue number with or without the substitution 
feature mentioned here) would allow you to have the equivalent of schema
defined symbolic constants.  Not quite what you example was doing, 
but similar.   
For example:

<xsd:schema ...>
        <xsd:simpleType name="length" base="double">
                <xsd:enumeration open="true">
                        <xsd:literal value="1000">1Km</xsd:literal>
                </xsd:enumeration>
        </xsd:simpleType>
...
</xsd:schema>

This would allow the length datatype to accept any legal double and in 
addition if the value matched any listed literal, 
the value would be substituted.


Is this response adequate ?
---------------------------

The XML Schema Working Group wants 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/

Received on Wednesday, 4 October 2000 18:10:26 UTC