xml-dev - Apples and Oranges

["joubin" <joubin@inch.com>]

[advance apology for undue familiarity in using the first names of the
participants, should you find that offensive.]


-----Original Message-----BEGIN

From: Ann Navarro <ann@webgeek.com>
Date: Tuesday, August 31, 1999 5:19 PM

The Namespaces rec was as controversial then as it is now, and opinions are
still widely divided.

Ann (personal view)

-----Original Message-----END


Hello Ann,

This begs the question of why W3C would choose to utilize this
"controversial" technology (XML-NS) as a building block of XHTML.  Your post
above doesn't elaborate on _what_ is causing the divergent views in W3C.
(Having followed this thread, I think that it is fair to say that many
veteran XML-DEV participants have been fairly articulate on why they are not
enamored of XML-NS:  they think it is broken; I tend to agree.)


If I may contribute my views on XHTML:

As Orin has effectively pointed out, the XTHML 1.0 spec (which I have read
;) is trying to squeeze 3 logical layers into one (the namespace); and
unfortunately, XML-NS is not up to the task.

My (perhaps naive) reading of the spec. tells me that there are actually 4
distinct (i.e. orthogonal) logical spaces which need to be mapped in order
to achieve the goals of this architecture; i.e. in my opinion, you (W3C) are
trying to map a 4 dimensional space with a one dimensional space.  (And a
flat one at that.)

For example, the spec presents the following 3 'types' of XHTML_1.0
document:

 tS: {(T)ransitional, (S)trict, (F)rameset}. // << {T, S, F}
 with corresponding  dS: {T.dtd, S.dtd, F.dtd}.

The problem here is that tS is not a homogenous set:

  -The relationship between T & S (T<->S) is NOT AT ALL
   analogous to T<->F, or to S<->F!

  -Both T<->F & S<->F are morphological relations.
   F is NOT a subset of either T or F.  Rather F is a morphological
   extension of T and S.  (And this is true for all future 'modules'
   as well.)

  - T<->S is a _dialectal_ relationship.
    A completely different relationship.

[tS is (somewhat) analogous to, say, {Verse, Prose, Romanticism}.]



So while _I agree with you_ that differentiation is just as important as
'commonalities', I also agree with David (& others) that have taken issue
with the _strategy_ that you (W3C) have chosen to achieve your goals.  This
flattening of orthogonal relational spaces into _one_ space will promote
ambiguity and _unnecessary_ complexity (whatever its magnitude; +3 or *3) in
the processing software.  Because in essence, **XHTML 1.0 delegates
infrastructural duties to the application layer.**  Sure it can be done.
The question is why?  It lacks clarity which quite likely will diminish its
utility.



In my opinion W3C should first complete the design of the _foundations_ of
ubiquitous information exchange architecture, AND THEN attempt to build
lovely structures on top of that foundation.  In that spirit, the efforts
put in to produce XHTML 1.0 are not in vain:  the spec clearly exposes the
anemic foundations on which W3C is trying to build this grand edifice.
Unless there is a fire out there that XHTML 1.0 (and only XHTML 1.0) can put
out, IMO it would be more fruitful for W3C to regroup and nail down the
_prerequisite_ technologies first.

Given that, I think XHTML (and XMLese objects in general) will (minimally)
need robust mechanism which allow a given instance of the object to be
mapped to:

1 - A Naming context,          // namespace proper, though currently flat
2 - A Revision context,        // which is NOT a namespace
3 - A Morphological context,   // which is NOT a namespace
4 - A Dialectal context.       // which is NOT a namespace



Thanks for listening.

/Best Regards/


Joubin
_____________________________________________________________________
member, alphazero LLC              202.462.1655                   dc


PS:  Bodies which make decisions which affect the collective should be OPEN,
given what we know of human nature.


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/ and on CD-ROM/ISBN 981-02-3594-1
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)