[
Lists Home |
Date Index |
Thread Index
]
- From: "Tolkin, Steve" <Steve.Tolkin@fmr.com>
- To: "'xml-dev@xml.org'" <xml-dev@XML.ORG>
- Date: Fri, 7 Jul 2000 11:08:23 -0400
-----Original Message-----
From: Jonathan Robie [mailto:Jonathan.Robie@SoftwareAG-USA.com]
Sent: Thursday, July 06, 2000 2:48 PM
To: xml-dev@xml.org
Subject: W3C XML Schema Questionaire
[I sent Johnathon my completed questionnaire. I am also posting these
excerpts here to further the discussion.]
...
9. Readability of Specifications
I must agree with the many people who have complained that the spec is very
difficult to understand. (I frequently read and write technical specs, and
have a background in database management systems and information retrieval
systems.) At a minimum the spec must be rewritten, even part 0. I did try
to read all three parts, but it became skimming pretty soon, so I apologize
if the issues I raise below are actually answered in the spec.
...
11. If the Working Group were to spend time redesigning Schema,
what do you think we should spend our time doing?
My primary focus is the production of XML from a database, relational or
object-relational, or from an application, and its consumption by another
database, application, or GUI.
A secondary focus is the production of XML from business documents, e.g.
Word, PowerPoint, Excel, and then indexing the output by a text oriented
search engine,
and then retrieval and display of the relevant fragments.
I have labelled each point with a short description.
Model: Get the underlying semantic model (aka InfoSet) correct. Use
"standard" computer science terminology, e.g. ordered tree, node, edge,
label, list, bag, unique, scope, etc. Try not to invent new jargon.
Evolution: Make sure that there is an easy way for consumers to ignore
elements
and attributes they do not want to process. This resembles the
functionality
provided by "architectural forms" but the implementation may be quite
different.
The larger issue is how to support schema evolution among a loosely coupled
set of producers and consumers.
Query: Make sure it is well coordinated with XML Query. (I know, this
makes the problem harder, because there are now two moving targets.)
IDs: Address the problem of how to generate ID (and IDREF) values from a
database.
The fact that an ID cannot be "look like" a pure number is a major
limitation. I understand that this comes from XML itself, rather than from
Schema. I further understand that this limitation is caused by wanting to
ensure that an XML document is a valid SGML document. Is it possible to
loosen up XML on this? Or is it possible for Schema to provide some help
for this? This is related to the issue of wanting a way to have IDs that
are not unique within the document as a whole, but which are unique within a
smaller "scope", e.g. for a specific element type, or (perhaps) in a
specific subtree associated with one input document in a "merged" document.
Order: Provide a way for the producer to identify when order matters
(children are a list) vs. when it does not (children are a bag). Similarly
provide a way for the consumer to specify this.
Hopefully helpfully yours,
Steve
--
Steven Tolkin steve.tolkin@fmr.com 617-563-0516
Fidelity Investments 82 Devonshire St. R24D Boston MA 02109
There is nothing so practical as a good theory. Comments are by me,
not Fidelity Investments, its subsidiaries or affiliates.
***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************
|