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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Namespaces, Architectural Forms, and Sub-Documents

[ Lists Home | Date Index | Thread Index ]
  • From: Paul Prescod <papresco@technologist.com>
  • To: xml-dev@ic.ac.uk
  • Date: Wed, 04 Feb 1998 13:16:58 -0500

Chris Maden wrote:
> 
> [David Megginson]
> > "namespace:gi" element type names are unsuitable for several reasons:
> 
> [...]
> 
> > Why are people worried about writing specs to solve a problem that
> > already has good, working, available solutions?
> 
> The problem (as I see it) is not one of including pieces of existing
> documents, nor of structural validation.  The main reason for
> namespaces is semantic inheritance.  

Architectural forms give you that.

> I want to write a scientific research paper quickly.  

The key word here is *quickly*. Architectural forms don't give you that.

> It should be *possible* to create a DTD to which such a document
> complies, but I am not as interested in automatic validation of a
> namespace document.  The interrelational issues are, I think, too
> complex to solve; in the example above, I would need to change the
> text-containing HTML elements' content models to include chemical and
> mathematical markup, and maybe allow HTML markup in MathML theorems.
> Pushing selected information into the content models is too ugly.

These issues are not complex at all. 

They are all handled nicely by the Japanese proposal. In a "modular
world", HTML would become a module that takes parameters such as
"object-types", "character span types", "block types" and so forth. You
pass in "MathML::Formula" as an "object-type" and the HTML %figure-type;
entity gets updated to reflect it. The issue is only complex in the
example you site because HTML was not designed to be modular because
SGML does not have a concept of DTD modules.

Even so, this is already dirt-common in SGML applications that don't
even *have* modules. You define a parameter entity and include the
entity. 

"<!-- In order to use the CALS table model, various parameter entity
     declarations are required.  A brief description is as follows:

..."

The only extra thing we need from modules is the namespace management
that helps us to avoid name clashes and a way to sneak parameter
entities or element names into the contained namespace.

 Paul Prescod
--
http://itrc.uwaterloo.ca/~papresco

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