Good stuff on XHTML modularization

[Len Bullard]

Thanks Tim.  I asked the question quoted, so if no 
one takes offense, I want to continue this on 
both lists.   See below.  I have edited the 
post to reply.  See Tim's post.

Background:  The X3D community is engaged 
in working out the binding of VRML97 to an XML 
application via an IDL.  We have serious concerns 
about the fluidity of the schema and datatype 
situation.  Use of encapsulated XML/X3D is demonstrated. 
Integration into an aggregate namespace is still by 
<object ..> in demonstrations and examples.

X3D is now at the stage where the initial 
designs for the DTD are stable and the first 
drafts for binding UTF-8 VRML and the XML are 
being written.   There are other issues such 
as the lack of array datatypes which will 
compromise the use of XML schemas for X3D schemas.

len

****************************************************8


Sebastian Schnitzenbaumer of Stack Overflow, a member of the HTML WG

Len Bullard, Intergraph Public Safety, a member of the 
X3D Contributors Group: 

Len:  There are some integration issues to be worked out for
namespaces.  For
example if a user customizes a DTD to be a conformant subset, is the
namespace the same?  If the user customizes a DTD but makes some changes
that affect names, how does the user indicate a variant?  Is is useful
to indicate the variant?   

Sebastian:  This is something the HTML WG has explored in great detail.

Modularization of XHTML is the framework for the HTML WG and 
other parties to organize the development of XHTML, that's why I 
sometimes use the nickname "XHTML Development Kit".

The subsets, extended subsets and variants versus namespace 
issue was a problem the HTML WG needed to solve.

One might ask, why modularization in the first place? 

Len:  Hmm not me.  I am a believer.  Got the MMTT t-shirt.  On 
to the code:

Sebatian:  Here is the model the HTML WG is currently developing:

Basis is HTML 4.0, a monolithic, stand-alone ML.

XHTML 1.0 is just the same thing in XML clothing, same 
functionality but XML notation, still one big thing.

Len: So, XML, A NOTATION, is a type.  It is the lexical 
and semantic description of a namespace.  Functionally, 
an object handler and schema for it? 

Sebastian:  XHTML 1.0 introduces the XHTML namespace, without implying 
versioning 

Len:  Why not?

Sebaatian: (NS URI is now "http://www.w3.org/1999/xhtml" BTW).

Len:  Thank you.

Sebastian:  Modularization slices XHTML 1.0 into a dozen "modules".
Think of 
a markup language as a cake. If you are sure that someone won't 
take the whole cake but only some slices, then it is better to define
"default cuts" instead of letting everyone randomly cut the thing into
pieces. 

Len:  I agree.  But mostly, I like it because it is 
very easy to slice parameter entities and element and attribute 
type declarations into hyperlinked name sets and/or dropdowns.  
I like to define my own defaults.
 
Ten years ago, we had systems that let us associate 
style to markup without the need to downtranslate.  
That is what we need now.  It makes the treeviews work. 
I don't want to navigate the structure tree of the 
screen containers.  I want to navigate the names of the 
datasets.  I think there will be a big seachange when 
the web lets go of seeing the screen in terms of 
one DTD, but as a composite of many in familiar controls.

Sebastian:  If Vendor A says I'm using slices X, Y, Z and Vendor B 
says Y, Z, P, then Author C will know the Y and Z is the same in 
both Vendor A's and Vendor B's implementation.

Len:  How?  Common schemas?  Namespaces don't name anything.  
They enable prefixing.  Prefixing is the lexical means 
to weave members of mutliple trees.  What trees are so 
defined and where?  Schemas?  What are the rules of the 
aggregate?  What are the logistics?

How do I know that Vendor B'sB and VendorA'sB work 
the same?  Conformance tests?  Who defines it?  
Who pays for the lack of conformance?  

Sebastian: Modularization of XHTML is the "module repository". In the
module 
repository, there are more modules than a single version of XHTML 
can use, for instance, there are two forms module (HTML 3.2 forms 
and HTML 4.0 forms) and two tables modules, etc.
  
Len:  Repositories.  M-Language communities like chat communities 
integrate by common interest.  Let a thousand flowers bloom, 
but if you ask any gardener, it takes a lot of work to get 
25 through the season.  Ecom-ecology.  Give them tools and 
get out of the way while the business hackers learn to 
apply them to create document databases instead of pages.

Sebastian: XHTML 1.1. is the same as XHTML 1.0, but the DTD is not 
monolithic, rather a specific combination of modules taken from the
module repository that aims to be a close match to XHTML 1.0.

Len:  The XHTML 1.1 design uses the name space of the parameter entity 
and a dot convention to assert a modular definition.  See 
AECMA 2000, MIL-M-28001, MIL-D-87269 for prior art.  Oster used the dot 
convention.  All were tested and found useful.  Standard.  
The DTD approach to modularization in XHTML is top flight 
for that form of defintion.  This works for DTD maintenance. 
As a means of specifying interoperable systems, it is only  
so so.  It is adequate name management.

Sebastian: Now comes the interesting part. The document "Building XHTML 
Modules" is the tutorial for any party (not only W3C) to create 
"XHTML conforming modules", a how-to guide on creating new 
modules similar in design to the those modules found at W3C's 
module repository.

Len: Yep.  he way to go..

Sebastian:  To answer the namespaces question, let's play through a
scenario:

Consortium releases module repository together with a specific 
combination known as StandardML. StandardML uses 12 of 15 
modules of the module repository. StandardML's 12 modules 
include 8 *mandatory* modules. All 15 modules of the module 
repository belong to the "StandardML namespace". Consortium is 
in control over StandardML namespace.

Len:  If you insist.  My thought is, give them the tools to 
define their own namespaces and figure out among themselves 
how to relate them.   Not that XHTML is not important.  
It absolutely is.  The W3C has a very good module repository. 

New DTDs may work for processes where rendering 
in a document model such as XHTML is not the best medium 
or always the host.  Sometimes it is the thing on 
the wall next to the h-anim smoking the cigarette.  
Or, it is a very simple XHTML, and a very complicated 
set of islands.  Language spaces defined as module 
repositories is just a way of satisfying a systemic 
issue with the shared definitions:  networks come 
down to registries.

XHTML is there in role as a page description language, 
but so are very cool new markup languages to use with it.  
I've played with VML.  Good logos.  Good basic 2D.  Really easy  
because it is JustMoreTags.  X3D is exciting to 
me because personally, I've waited a long time for 
a medium in which the entire range of hypermedia 
was expressible in markup.   These are exciting 
times for some of us.  Didn't think it would ever come. 
Using data islands and different rendering languages 
that can be combined by effect and animation is fantastic.

Sebastian:  As an example, here is a sample file of XHTML-FML, an XHTML 
family member using XHTML 1.1 without the HTML 4.0 Forms 
module but instead with an additional namespace of five new 
Forms Markup Language modules:

<?xml version="1.0"?>
<!DOCTYPE html PUBLIC 
  "-//OVERFLOW//DTD XHTML-FML 1.0//EN" 
  "http://www.mozquito.org/dtd/xhtml-fml1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" 
  xmlns:x="http://www.mozquito.org/xhtml-fml">
<head>
<title>Untitled</title>             
<meta name="generator" content="Mozquito Factory 1.0" />
</head>
<body>

<x:form>
...
</x:form>

</body>
</html>

Check http://www.mozquito.org/factory to see the implementation.

Len: That is very cool.  

Regards, Sebastian

Len:  Thank you very much for taking the time to answer me.  
Your description is lucid, and easy to understand.

Regards, Len


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)