OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: Access Languages are Tied to Schemas

[ Lists Home | Date Index | Thread Index ]
  • From: "Rick Jelliffe" <ricko@allette.com.au>
  • To: <xml-dev@ic.ac.uk>
  • Date: Fri, 21 Nov 1997 12:53:17 +1100

> From: Jonathan Robie <jwrobie@mindspring.com>

> The following properties of object models are easily represented in SGML/XML:
> o       Identity
> o       State
> o       Type
> These properties are not easily represented:
> o       Behavior (except for in languages that allow methods to be
> represented as data, e.g. Java)
> o       Encapsulation constraints

I think you miss what is perhaps *THE* most important thing that SGML content
models represent:  sequence.

This is one of the essential distinguishing features of SGML.

If I have 

<p>Refer also to 
	<title>XML draft</title>
</citation> for more info.</p>

then the sequence of elements and data in to citation element 
are vitally critical.  Sequence is not an artifact of formatting,
in many cases, but as intrinsic to the data as encapsulation
and so on.  

The problem I see with so many discussions of the virtues of object-oriented
inheritance systems is that they fail to discuss how inheritance works with
sequence.  It seems to be an issue tucked aside.  

For example, if the content model of the above is

	<!ELEMENT citation   ( title, text, url)>

and I want to use the citation element type as a supertype, and derive a 
new element type with the following content model

	<!ELEMENT citation   ( title, text, name, text, url )>

so I can say

<p>Refer also to <citation>
	<title>XML draft</title>
	<text>edited by<text> 
	<name>McQueen, Bray, Paoli</name>
</citation> for more info.</p>

This kind of adding element types in particular points in sequences is,
as I say, one of the most basic requirements for any real work.  

I am very interested in seeing inheritance-based models that address
this issue: that would be great.  

The best idea I have some up with is the following: to allow a new keyword
	#OTHER  (or #ANY) 
to be allowed in content models, to represent any one unambiguous element type.
This allows the creator of the original content model the ability to 
declare points in content models which are publically available for extension
by derived element types (declared or undeclared).

I currently think that any inheritance-based declaration system must presuppose
such explicit inheritance points.  I think it is merely a matter of strong typing
and interface control.

Rick Jelliffe

Rick Jelliffe

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS