With all due respect to Simon St. Laurent, I believe that Tim
Berners-Lee
>was correctly precise when he wrote "the document corresponding to the
>namespace URI becomes
>the place where the namespace-author can put *definitive*
>information about the intent of the namespace." (Emphasis in the
original).
The only information that properly belongs in a namespace is a list of
names.
All other information, however convenient, is not namespace information
but something else: what is this "intent" business? There is no mention
of
"intent" in the namespaces spec that I recall, quite the opposite. The
fundamental justification for namespace is to be free from intent.
There is no W3C method to define a namespace as list of names. There is
no
W3C method to declare which schema should be used, akin to the
stylesheet declaration. In the absense of these, of course people will
try to
turn namespaces URIs into schema declaration URLS. The W3C should
provide a proper way to define namespaces (as simple lists) and a
way to declare schemas. (Furthermore, the idea of a namespace-author
being in some way the controller of the resource for a schema is bad;
a schema identifier (or a namespace list) should be identified using
the URI equivalent of a Formal Public Identifier: I can ask some service
to provide me that schema (or that namespace list) in any format
that anyone has chosen to make available.)
>While there are many processes that can be applied to a document, and
>correspondingly many specifications of those processes, there can be,
for a
>given term in a namespace, at most one correct *definition*.
Again, the only declaration information that is proper to a namespace
is a list of names. A content model is a schema, and nothing to do with
names in a namespace, in particular.
>[Someone] wrote that, although a schema may be somehow associated with
a
Me among others
>namespace, the "meaning" of markup will be determined in a number of
ways
>such as style sheets, or procedural code, or maybe the schema. I
believe
>this understates the importance of the schema. A schema makes a
>contribution to the Infoset. It does this by providing default values
and --
>under some recent proposals -- by indicating type information, which
may be
>considered also a form of default value. Elements defined by a schema,
when
>used in an instance document in a validating processor, will have these
>default values available, and this fact is pertinent to the author of
the
>document. This means that an element is incompletely read if the schema
for
>it is not read.
This assumes that default values are not conditional or parameterized,
which in turn assumes a particular form for schemas.
But the current Infoset draft only has "the information available in a
well-formed XML document". So there are levels of Infoset depending
on which data is considered, in progressive fashion. In s. 7 "What is
not in the information set":
1. The information in the XML declaration and text declarations.
2. Element content models from ELEMENT declarations.
3. The grouping and ordering of attribute declarations in ATTLIST
declarations.
So Andrews view seems novel. In DOM level 1 also
there is no access to content model information, which suggests that the
incompleteness of an element without a content model is minimal for
basic use of that element. Canonical XML does not include DTD or
schema.
(Furthermore, some people have reservations that default values
are in fact part of a schema at all. )
>Unlike the various processings that may or may not be applied to a
document,
>a cited schema is part of the information conveyed by the document.
When a
>namespace has an associated schema, that schema is part of the input to
any
>further complete processing of the referencing document. A schema is
not on
>par with other forms of processing that might be specified, say by
style
>sheets or procedural code. It is prior to other processing.
Again, Andrew is simply conflating schema and namespace. The idea that
he and Tim are putting forward is that a language is defined by a single
set of content models; this confuses "language" with "grammar" and
is disproved by long-standing SGML practise, in which variants of
a language can be defined in the same DTD (selected by marked sections,
or by simply overriding parameter entity declarations).
I think the problem is the bad idea that content models *define* a
language rather
than simply *describe* or *declare* it. The "blink" element is not
strict
HTML; it is only an artifact of the formalism used to describe HTML
(content models on the child axis) that using a blink attribute should
require the child element to be transitional HTML. There have been
so much criticism of DTDs and their particular limitations of
expressiveness,
yet this namespace issue utterly is dependent on a DTD-based
understanding
of what a schema should be.
An element is not defined by its content model, unless it and its
content model
are highly coupled semantically, such as tables and rows. But frames
and
the root html element are not highly coupled semantically. DTDs and
content models (on the child axis) provide no way to model this: we
either
have ANY or a highly coupled content model. Take the example of
and : these are not semantically coupled element types--
the element type adheres to running text and the element
uses running text. If the element is removed, it is the
declarations
for running text that should be changed, not the declarations for .
DTDs only provide parameter entities for this, which disguises this
basic
modeling truth. The XML Schema draft got it more right by providing
archetypes as a first-class object.
>Further, I expect that one can argue that a namespace is an abstract
concept
>denoting a set of names, and this argument is true, so far as it goes,
but
>it does not go far enough: For specific processing, to make use of a
>namespace one needs to know what names are in it, which are not, and
what
>the meaning is for each name
Here is the crux: Andrew is saying a namespace mechanism should provide
more
than just a space of names! He says it should also provide meanings. If
it does so,
it is not a namespace, but a schema. Andrew is saying that we should
not
have namespaces but schemas. This is a legitimate view, but it utterly
flies in the face of the current spec and all previous pronouncements on
it.
If W3C says a namespace is a schema, they should withdraw the XML
Namespaces
Spec immediately. As I emailed a month ago, Namespaces is dead. Not by
neglect but by abuse.
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/ 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)
From ann at webgeek.com Thu Sep 16 19:14:47 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:03 2004
Subject: Another look at namespaces
In-Reply-To: <4.2.0.58.19990916125508.00b3d550@pophost.arbortext.com>
References: <4.1.19990916123524.024ab640@mail.webgeek.com>
<3.0.5.32.19990916091610.00cc9370@corp.infoseek.com>
<006101beffba$a2984280$a60a1712@col.w3.org>
Message-ID: <4.1.19990916130806.0249d1a0@mail.webgeek.com>
At 01:03 PM 9/16/99 -0400, Eve L. Maler wrote:
>Not to pick nits, but the August 29 statement just observed a correlation;
>when I first read it, I didn't take it to be providing an actual reason for
>the decision. The "as direct a mapping as possible" language does indeed
>give insight into the decision to go with a one-to-one DTD/NS mapping,
>though I think that the confusion reigning about the purpose of NSs puts
>the rationale on shaky foundations not of the WG's making.
I can see where that observation may have occured.
However, I do feel that a relatively cursory glance at the actual documents
and Activity statement further solidify the charge to the WG of
transforming all of HTML 4.0 (three versions) into XML, which is what we did.
I think it's a rather spurious suggestion that the entire discussion would
have been avoided
> >This is a rationale. Including this with the recent draft
> >would have saved us all a lot of e-mail traffic.
had the statement been made in the manner that Tim did, only 3-4 weeks ago.
The abstract seems to me to be very self explanatory: This specification
defines XHTML 1.0, a reformulation of HTML 4.0 as an XML 1.0 application,
and three DTDs corresponding to the ones defined by HTML 4.0.
It still, however, doesn't definitely answer the namespace issue, though I
personally believe it supports it.
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From wunder at infoseek.com Thu Sep 16 19:16:13 1999
From: wunder at infoseek.com (Walter Underwood)
Date: Mon Jun 7 17:15:03 2004
Subject: Binary-encoding of XML for communication
In-Reply-To: <002f01bf0036$4e6a8160$85247385@ssel.toshiba.co.jp>
References: <805C62F55FFAD1118D0800805FBB428D02BBFEAB@cc20exch2.mobility.com>
Message-ID: <3.0.5.32.19990916101657.00a6de40@corp.infoseek.com>
At 08:26 PM 9/16/99 +0900, Shinichiro HAMADA wrote:
>Hello, all.
>
>We are trying to develop a Server/Clients network system with XML. In this
>system, Clients read structured data and send them as XML data to a server.
>
>We estimate too heavy to communicate text-based XML and to decode/encode it
>to/from XML object tree. So we think it's desiable to communicate XML data
>as binary serialized object tree. And it's better that the binary code is
>open format.
Do you need to optimize communication (bytes sent/received) or
CPU (time spent parsing)?
If it is communication, try compressing the XML with a standard
algorithm. See the "content-coding" part of HTTP 1.1 for some
samples.
If it is CPU, benchmark XML parsers. Also, use an event-based
parser (SAX) to build your data structures directly. With a
DOM-based parser, you will build objects twice -- once for
the DOM and once for your application.
wunder
--
Walter R. Underwood
wunder@infoseek.com
wunder@best.com (home)
http://software.infoseek.com/cce/ (my product)
http://www.best.com/~wunder/
1-408-543-6946
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)
From donpark at docuverse.com Thu Sep 16 19:22:03 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun 7 17:15:03 2004
Subject: Another look at namespaces
In-Reply-To: <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08>
Message-ID: <000001bf0068$8d5f6020$15a8fea9@w21tp>
>With all due respect to Simon St. Laurent, I believe that Tim
>Berners-Lee
>was correctly precise when he wrote "the document corresponding to the
>namespace URI becomes
>the place where the namespace-author can put *definitive*
>information about the intent of the namespace." (Emphasis in
>the original).
Andrew,
Allow me to observe that:
1. 'Can' does not make 'Must' nor 'Should'.
2. 'Intent' of a namespace is not necessarily same as 'Schema'.
I believe that:
1. A namespace is empty of meaning beyond being distinguishable from other
namespaces.
2. A name within a namespace is also meaningless beyond being
distinguishable from other names in the namespace.
3. Meaning of a name requires a frame of reference.
While a schema can be a frame of reference for the meaning of a name, a
family of schemas can be used as well. I believe this is precisely what
should happen with the 'family' of XHTML schemas.
Everything you stated depends on the assumption that a direct relationship
exists between a namespace and a schema. I believe you can state the same
if there was a direct relationship between a namespace and a family of
schemas. We currently do not have a formal mechanism to define a family of
schemas, but if there was, we should be able to define relationships between
the member schemas as well the membership requirements. One happy family
afterall.
Best,
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
From ricko at allette.com.au Thu Sep 16 19:22:57 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:03 2004
Subject: Another look at namespaces
Message-ID: <006801bf0068$fcdb9130$1ff96d8c@NT.JELLIFFE.COM.AU>
From: Ann Navarro
>At 09:16 AM 9/16/99 -0700, Walter Underwood wrote:
>>At 04:41 PM 9/15/99 -0400, Tim Berners-Lee wrote:
>>>
>>> [...] the HTML 4.0 spec defined three, and XHTML was required to be
>>>as direct a mapping from HTML 4.0 to XML as possible.
>>
>>This is a rationale. Including this with the recent draft
>>would have saved us all a lot of e-mail traffic.
>
>This was said way back at the beginning (August 29)
>
>http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Aug-1999/0370.html
>
>Quoting myself "No, we've not confused them. We happen to have three
>'flavors' of XHTML 1.0
>(the first deliverable from the XHTML project, not the end sum of our
>work), that essentially map to the three flavors of HTML 4.0."
But HTML 4.0 does not define three namespaces. The term namespace
or its concept is never even used in it, that I can see. It specifies
three
DTDs, but since a schema is not a namespace, so what? T.B-L's
argument is not that HTML 4 has three namespaces, but that HTML 4
has three DTDs, and so does is not an adequate rationale.
In any case, since HTML 4.0 was finished before the namespace spec
(1997-12-18 v. 1999-01-14) , how could it specify three namespaces?
Does the HTML WG have some spirit guide :-)
It seems clear that the HTML team have some mental concept of namespaces
which exists independently of what the W3C specification actually
allows.
If a W3C specs can be utterly overturned in such a way, what is their
value?
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/ 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)
From spreitze at parc.xerox.com Thu Sep 16 19:26:42 1999
From: spreitze at parc.xerox.com (Mike Spreitzer)
Date: Mon Jun 7 17:15:03 2004
Subject: code generation from XML datatype definitions: anyone interested?
In-Reply-To: <022d01bf0060$d9a828c0$0300000a@cygnus.uwa.edu.au>
Message-ID: <001401bf0068$37db7030$27d1000d@deimos.parc.xerox.com>
> ... Does the XML Data Binding spec address calculation of
> attributes on the basic of other (possibly inherited) attributes?
I would be surprised to see that, based on the requirements discussion
available so far.
> I would imagine building on that spec.
If you mean "building" as in "layering", that would probably be ideal. If
you mean "building" as in "modifying", it might be better to explain now
(to the JCP) why you have additional requirements.
Mike
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)
From ricko at allette.com.au Thu Sep 16 19:33:24 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:03 2004
Subject: (minor correction) Re: Another look at namespaces
Message-ID: <007f01bf006a$7574de70$1ff96d8c@NT.JELLIFFE.COM.AU>
From: Rick Jelliffe
>I think the problem is the bad idea that content models *define* a
> language rather than simply *describe* or *declare* it. The "blink"
> element is not strict HTML; it is only an artifact of the formalism
> used to describe HTML (content models on the child axis) that using
> a blink attribute should require the child element to be transitional
HTML.
"child element" should be "containing element"
Rick
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)
From ann at webgeek.com Thu Sep 16 19:42:46 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:03 2004
Subject: Another look at namespaces
In-Reply-To: <006801bf0068$fcdb9130$1ff96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <4.1.19990916133951.024af920@mail.webgeek.com>
At 01:29 AM 9/17/99 +0800, Rick Jelliffe wrote:
>But HTML 4.0 does not define three namespaces. T
>In any case, since HTML 4.0 was finished before the namespace spec
>(1997-12-18 v. 1999-01-14)
You've answered your own question there.
>It seems clear that the HTML team have some mental concept of namespaces
>which exists independently of what the W3C specification actually
>allows.
There's no basis for that other than assumption.
The HTML WG doesn't live in a cave, nor an alternate reality. By the
conversations *here* it's clear that the community at large doesn't agree
on the value and application of namespaces. That doesn't follow then, that
the HTML WG simply can't read a spec or understand the obvious. :)
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From shane at aptest.com Thu Sep 16 19:48:04 1999
From: shane at aptest.com (Shane P. McCarron)
Date: Mon Jun 7 17:15:03 2004
Subject: Another look at namespaces
References: <3.0.5.32.19990916091610.00cc9370@corp.infoseek.com>
<006101beffba$a2984280$a60a1712@col.w3.org> <4.2.0.58.19990916125508.00b3d550@pophost.arbortext.com>
Message-ID: <37E12DE0.8991665F@aptest.com>
The XHTML 1.0 Proposed Recommendation
(http://www.w3.org/TR/1999/PR-xhtml1-19990824) states in its Abstract
and in Section 1.0 (What is XHTML?) that the specification is a
reformulation of the three HTML 4.0 DTDs into three XML applications. We
absolutely meant this to say that there are three distinct XML
applications corresponding to the three distinct SGML applications of
HTML 4.0. I will add a comment to the issue database that this was
unclear and try to make an editorial change to the document to clarify
it during the transition from PR to Recommendation (assuming we ever get
that far ;-).
Shane McCarron
Speaking as editor of the XHTML 1.0 Proposed Recommendation
"Eve L. Maler" wrote:
>
> Not to pick nits, but the August 29 statement just observed a correlation;
> when I first read it, I didn't take it to be providing an actual reason for
> the decision. The "as direct a mapping as possible" language does indeed
> give insight into the decision to go with a one-to-one DTD/NS mapping,
> though I think that the confusion reigning about the purpose of NSs puts
> the rationale on shaky foundations not of the WG's making.
>
> Back to lurking,
>
> Eve
>
> At 12:44 PM 9/16/99 -0400, Ann Navarro wrote:
> >At 09:16 AM 9/16/99 -0700, Walter Underwood wrote:
> > >At 04:41 PM 9/15/99 -0400, Tim Berners-Lee wrote:
> > >>
> > >> [...] the HTML 4.0 spec defined three, and XHTML was required to be
> > >>as direct a mapping from HTML 4.0 to XML as possible.
> > >
> > >This is a rationale. Including this with the recent draft
> > >would have saved us all a lot of e-mail traffic.
> >
> >This was said way back at the beginning (August 29)
> >
> >http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Aug-1999/0370.html
> >
> >Quoting myself "No, we've not confused them. We happen to have three
> >'flavors' of XHTML 1.0
> >(the first deliverable from the XHTML project, not the end sum of our
> >work), that essentially map to the three flavors of HTML 4.0."
> >
> >
> >But apparently nobody wanted to hear it.
> >
> >Ann
> >
> >---
> >
> >Author of Effective Web Design: Master the Essentials
> >Coming in September --- Mastering XML
> >
> >Founder, WebGeek Communications http://www.webgeek.com
> >Vice President-Finance, HTML Writers Guild http://www.hwg.org
> >Director, HWG Online Education http://www.hwg.org/services/classes
> >
> >
> >
> >
> >
> >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)
>
> 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)
--
Shane P. McCarron phone: +1 612 434-4431
ApTest fax: +1 612 434-4318
mobile: +1 612 799-6942
e-mail: shane@aptest.com
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)
From ricko at allette.com.au Thu Sep 16 19:54:19 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:03 2004
Subject: What XHTML should do with namespaces
Message-ID: <009a01bf006d$67f97460$1ff96d8c@NT.JELLIFFE.COM.AU>
1) There should be three namespaces:
base
slack
frames
2) These namespace should be formally defined by means of a simple
list in each case, so that every HTML 4 element is allocated to one only
namespace each.
3) There should be a EXTENSIBLE XHTML DTD created, in which all
relevant attributes are declared for elements, but all element types
them
selves have no definitions or definitions of ANY. It is this DTD that
documents should be transmitted with. It allows attribute defaulting
and is open for extensibility, but provides weak type checking by
recipient validators.
4) There should be 3 other DTDs created:
strict (includes only elements from the base namespace)
transitional (includes only elements from the base and slack
namespace)
frameset (includes elements from all namespaces)
These three DTDs can be used for server/generator/tidier programs
but are not for usual publically-distributed documents.
This is the correct use of namespaces IMHO. Also, it makes XHTML
documents extensible without DTD rewriting, which the current
XHTML specification does not allow. In a sense, "strictly conforming
XHTML documents" should be called non-extensible HTML!
XHTML should start off mandating this kind of weakly typed DTD
to allow extensibility: the strong typing should be provided by
future XML Schema languages, with the DTD becoming merely
a way to declare entities, transport comments, define attributes
and defaults tersely, and for providing some kinds of document-specific
restrictions to schemas.
XHTML' approach to namespace is wrong because the whole thing is
mistaken: lets not enshrine closed content models any more! XHTML
should support extensibility!
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/ 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)
From shane at aptest.com Thu Sep 16 20:03:12 1999
From: shane at aptest.com (Shane P. McCarron)
Date: Mon Jun 7 17:15:04 2004
Subject: Another look at namespaces
References: <199909161638.MAA10671@hesketh.net>
<4.1.19990916122123.0248fbf0@mail.webgeek.com>
<199909161602.MAA09307@hesketh.net>
<5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> <199909161659.MAA11511@hesketh.net>
Message-ID: <37E13172.9FF0174A@aptest.com>
"Simon St.Laurent" wrote:
> Is there _anything_ else besides their names that distinguishes these flavors?
Sure.
XHTML Frameset has a completely different content model than the other
two. Its root element is html, but that html element may NOT contain a
body element. Instead, it contains a frameset element that defines the
collection of frames. These frames have some weird inherent behaviour
that cannot be described by existing schema technology (various panels
are defined in the window, one per defined frame). To be clear, an XHTML
Frameset document as NO CONTENT. Instead, it refers to content. Is
this stupid? Sure. However, it is a faithful representation of HTML
4.0.
XHTML Transitional has a different content model than Strict in that it
is more permissive. XHTML Transitional may be a superset of XHTML
Strict, but I have never done the evaluation to be certain. I am certain
that they are significantly different. In particular, XHTML Transitional
contains all sorts of stuff that is eliminated in XHTML 1.1. XHTML
Strict only has a few items that are removed in XHTML 1.1 (e.g. the name
attribute on the a element is eliminated in favor of the id attribute).
> >Information about those namespaces may, if the W3C chooses to follow this
> >path, be obtained from a schema, DTD, or other data source at the end of
> >that URI.
>
> Or, since this is an XML 1.0 application, you could just read the DOCTYPE
> declaration and not try to map namespace URIs to places where the W3C might
> (but won't comment on publicly at present) want to go someday.
Absolutely. And, since XHTML 1.0 requires a DOCTYPE declaration, you can
be confident that one will be present in XHTML 1.0-conforming documents.
Moving forward, as the HTML Working Group completes its work on Document
and Client profiles (which might just be requirements to CC/PP, who
knows), I expect that the group will define elements that allow document
authors specify:
a pointer to a document profile
a complete, embedded document profile
information about the schema
information about how the schema is based upon other, well known
schema (like XHTML)
etc.
However, that is a future problem. The current problem is finding a way
through this morass so that we can publish the first baby step toward a
better, more interoperable web. That is XHTML 1.0. What do we need to
do to get on with it?
--
Shane P. McCarron phone: +1 612 434-4431
ApTest fax: +1 612 434-4318
mobile: +1 612 799-6942
e-mail: shane@aptest.com
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)
From ricko at allette.com.au Thu Sep 16 20:11:24 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:04 2004
Subject: Another look at namespaces
Message-ID: <00a101bf006f$c4ba8070$1ff96d8c@NT.JELLIFFE.COM.AU>
From: Ann Navarro
>At 01:29 AM 9/17/99 +0800, Rick Jelliffe wrote:
>>It seems clear that the HTML team have some mental concept of
namespaces
>>which exists independently of what the W3C specification actually
>>allows.
>
>There's no basis for that other than assumption.
No, my basis is the emails on this subject, my involvement in the XML IG
at the time the namespaces spec was developed, and subsequent comments
by many people.
>The HTML WG doesn't live in a cave, nor an alternate reality. By the
>conversations *here* it's clear that the community at large doesn't
agree
>on the value and application of namespaces. That doesn't follow then,
that
>the HTML WG simply can't read a spec or understand the obvious. :)
My point is not that they cannot, but that they have not in this case.
To suggest
that a WG can try to fit a square peg into a round hole does not mean
that
they live in an "alterate reality", merely that they have lost the plot
on one
particular issue, perhaps simply because of youthful enthusiasm.
B.t.w., I think your reaction about "caves and alternate reality" is a
bit too
strong on this; if we say that this use of namespaces is novel and has
not
been justified or even attempted to have been justified in the past,
that does
not mean we are accusing the HTML WG of being a conspiracy.
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/ 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)
From simonstl at simonstl.com Thu Sep 16 20:20:10 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:04 2004
Subject: Applications, DTDs, Namespaces (was Re: Another look at
namespaces)
In-Reply-To: <37E12DE0.8991665F@aptest.com>
References: <3.0.5.32.19990916091610.00cc9370@corp.infoseek.com>
<006101beffba$a2984280$a60a1712@col.w3.org>
<4.2.0.58.19990916125508.00b3d550@pophost.arbortext.com>
Message-ID: <199909161822.OAA15351@hesketh.net>
At 12:50 PM 9/16/99 -0500, Shane P. McCarron wrote:
>The XHTML 1.0 Proposed Recommendation
>(http://www.w3.org/TR/1999/PR-xhtml1-19990824) states in its Abstract
>and in Section 1.0 (What is XHTML?) that the specification is a
>reformulation of the three HTML 4.0 DTDs into three XML applications. We
>absolutely meant this to say that there are three distinct XML
>applications corresponding to the three distinct SGML applications of
>HTML 4.0. I will add a comment to the issue database that this was
>unclear and try to make an editorial change to the document to clarify
>it during the transition from PR to Recommendation (assuming we ever get
>that far ;-).
>
>Shane McCarron
>Speaking as editor of the XHTML 1.0 Proposed Recommendation
I'm not sure that this actually clarifies the genuinely contentious issues.
'Three distinct XML applications' still doesn't imply 'three distinct XML
namespaces'. The Namespaces in XML Recommendation only describes software
applications, not 'XML applications'. There doesn't appear to be any
correlation between applications and namespaces, and I think that issue
(also described as DTDs/schemas and namespaces) is what's keeping this
discussion grinding along, going nowhere quickly.
'Vocabularies' might be a better word to use (more in keeping with the NiX
rec), though there the overlap between the three vocabularies makes it hard
to justify.
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From simonstl at simonstl.com Thu Sep 16 20:21:05 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:04 2004
Subject: Another look at namespaces
In-Reply-To: <37E13172.9FF0174A@aptest.com>
References: <199909161638.MAA10671@hesketh.net>
<4.1.19990916122123.0248fbf0@mail.webgeek.com>
<199909161602.MAA09307@hesketh.net>
<5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08>
<199909161659.MAA11511@hesketh.net>
Message-ID: <199909161823.OAA15376@hesketh.net>
At 01:05 PM 9/16/99 -0500, Shane P. McCarron wrote (a better answer than I
hoped to receive):
>"Simon St.Laurent" wrote:
>> Is there _anything_ else besides their names that distinguishes these
flavors?
>
>Sure.
>
>XHTML Frameset has a completely different content model than the other
>two. Its root element is html, but that html element may NOT contain a
>body element. Instead, it contains a frameset element that defines the
>collection of frames. These frames have some weird inherent behaviour
>that cannot be described by existing schema technology (various panels
>are defined in the window, one per defined frame). To be clear, an XHTML
>Frameset document as NO CONTENT. Instead, it refers to content. Is
>this stupid? Sure. However, it is a faithful representation of HTML
>4.0.
The question in full was 'Is there anything else besides [the DTDs
- from prev para - and ] their names that distinguishes these flavors.
'Completely different content model' is still well within the realm of
DTDs/schemas. 'Weird inherent behavior' at least moves beyond that, but
I'm not sure it justifies an additional namespace.
>XHTML Transitional has a different content model than Strict in that it
>is more permissive. XHTML Transitional may be a superset of XHTML
>Strict, but I have never done the evaluation to be certain. I am certain
>that they are significantly different. In particular, XHTML Transitional
>contains all sorts of stuff that is eliminated in XHTML 1.1. XHTML
>Strict only has a few items that are removed in XHTML 1.1 (e.g. the name
>attribute on the a element is eliminated in favor of the id attribute).
This is all represented by the DTD, however - I don't think there's any
need to go beyond that and distinguish strict from transitional as far as
identifiers are concerned.
>> >Information about those namespaces may, if the W3C chooses to follow this
>> >path, be obtained from a schema, DTD, or other data source at the end of
>> >that URI.
>>
>> Or, since this is an XML 1.0 application, you could just read the DOCTYPE
>> declaration and not try to map namespace URIs to places where the W3C might
>> (but won't comment on publicly at present) want to go someday.
>
>Absolutely. And, since XHTML 1.0 requires a DOCTYPE declaration, you can
>be confident that one will be present in XHTML 1.0-conforming documents.
>Moving forward, as the HTML Working Group completes its work on Document
>and Client profiles (which might just be requirements to CC/PP, who
>knows), I expect that the group will define elements that allow document
>authors specify:
>
> a pointer to a document profile
> a complete, embedded document profile
> information about the schema
> information about how the schema is based upon other, well known
> schema (like XHTML)
> etc.
>
>However, that is a future problem. The current problem is finding a way
>through this morass so that we can publish the first baby step toward a
>better, more interoperable web. That is XHTML 1.0. What do we need to
>do to get on with it?
Simplify would be a good first step. Give XHTML 1.0 a single namespace for
this version, and then get on with the more exciting work that follows.
Don't complicate matters by adding namespaces on top of the DOCTYPE
declaration you promise to use faithfully.
But remember, I haven't paid any membership dues.
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From shane at aptest.com Thu Sep 16 20:29:07 1999
From: shane at aptest.com (Shane P. McCarron)
Date: Mon Jun 7 17:15:04 2004
Subject: What XHTML should do with namespaces
References: <009a01bf006d$67f97460$1ff96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <37E13772.86FD1331@aptest.com>
Rick proposes an interesting model. This model is largely already
supported in XHTML Modularization. XHTML Modularization provides a
toolkit for developing markup languages from modules. These modules are
defined abstractly, and then mapped onto an implementation (an XML DTD,
but an XML Schema is also possible). These modules can be collected
together to form arbitrary XHTML-family markup languages. Users can also
develop new modules with their own elements and attributes, extend the
content models of XHTML-provided modules, etc.
These are defined in Building XHTML Modules, Modularization of XHTML,
and XHTML 1.1. These public documents are available at
http://www.w3.org/TR
The working group never intended XHTML 1.0 to be extensible. It is a
bridge. It is there to help HTML document authors make the transition
to XML in a way that is backward compatible with existing browsers.
Nothing more. Don't read too much into it. It will drive you crazy.
With regard to namespaces, IMO the work on Modularization is orthogonal
to namespaces. It is not the intent of the working group to define
multiple namespaces within the modularization infrastructure. You could,
I supposed, use modularization to define a collection of namespaces that
represent different collections of functionality. These namespaces could
then be cobbled together in compound documents. However, the resulting
documents would not be validatable.
Regardless, the modularization architecture of XHTML is designed to
address the goal of extensibility on a massive scale. It can be mapped
into XML Schema or XML DTDs. It can rely upon XML namespaces or not. I
suggest you all check these documents out before worrying about the
extensibility of XHTML.
--
Shane P. McCarron phone: +1 612 434-4431
ApTest fax: +1 612 434-4318
mobile: +1 612 799-6942
e-mail: shane@aptest.com
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)
From ann at webgeek.com Thu Sep 16 20:25:48 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:04 2004
Subject: Another look at namespaces
In-Reply-To: <00a101bf006f$c4ba8070$1ff96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <4.1.19990916142517.024ddae0@mail.webgeek.com>
At 02:17 AM 9/17/99 +0800, Rick Jelliffe wrote:
>that does
>not mean we are accusing the HTML WG of being a conspiracy.
No, but you're basically suggesting that we're thick.
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From ricko at allette.com.au Thu Sep 16 21:03:44 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:04 2004
Subject: Another look at namespaces
Message-ID: <00bc01bf0076$ed87bca0$1ff96d8c@NT.JELLIFFE.COM.AU>
From: Ann Navarro
>At 02:17 AM 9/17/99 +0800, Rick Jelliffe wrote:
>
>>that does
>>not mean we are accusing the HTML WG of being a conspiracy.
>
>No, but you're basically suggesting that we're thick.
Come on, stop making this into some personal thing. I said
" It seems clear that the HTML team have some mental concept of
namespaces which exists independently of what the W3C specification
actually allows". Perhaps this concept is an improvement; but
don't expect anyone to swallow a major, last minute, unexpected
use of namespaces that goes against all the discussions at the time
and against all public statements since that time.
There still has been no justification for it: TB-Ls comment that
HTML has three DTDs so should have three namespaces puts
the cart before the horse; Andrew Layman's comment that there
are definitional schemas and that these set namespaces is undebated
and can be proved wrong by the simple example of RDF, which
defines a namespace but allows major parts of schemas undefined,
notably the GIs (element type names) of second and third tier
elements. So if RDF is a legitimate use of namespaces, and if
namespaces come from definitional schemas, then the definitional
schema does not need to include a specific content model: if can
be extended and refined willy nilly. Following this line, the only
thing in a schema left ultimately is a list of names. However, it
is quite possible for someone to make a list of names, and use some
in one DTD and others in another DTD, with no mixing. This
is a legitimate use of namespaces in the current spec; again,
it shows that there is no nessecary connection between a "definitional
schema" and a namespace, unless the definitional schema is a
simple list of names (in some format TBA).
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/ 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)
From ricko at allette.com.au Thu Sep 16 21:20:16 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:04 2004
Subject: More than three namespaces for XHTML? (was Re: What XHTML should do with namespaces)
Message-ID: <00c101bf0079$362e4cb0$1ff96d8c@NT.JELLIFFE.COM.AU>
From: Shane P. McCarron
>Regardless, the modularization architecture of XHTML is designed to
>address the goal of extensibility on a massive scale. It can be mapped
>into XML Schema or XML DTDs. It can rely upon XML namespaces or not. I
>suggest you all check these documents out before worrying about the
>extensibility of XHTML
I had. Whether XHTML modularization and profiles rely on namespaces
(which surely they should) is not the issue here. The issue is that the
XHTML namespaces should not be equated with the HTML DTDs.
Actually, it is an issue: if namespaces are to be taken from DTD, then
every different possible combination of modularized HTML has its own
effective DTD and will therefore need its own namespace.
So we are not talking about 3 namespaces for XHTML, but potentially
dozens!
I have been trying to figure out what on earth the HTML WG is thinking.
The best I can come up with is that they do not think that HTML
processors will use the namespace prefixes: they will key off the local
name only and they expect that qualified names will never be used,
because the namespace declaration on the html element will preclude it.
In other words, there is some kind of tacet assumption that qualified
names are never used and that, because then CSS will work fine, there is
really no problem. So it would not be an issue if there were 1,000
namespaces, because the namespace just selects the DTD variant. However,
this
view is not correct: XHTML will be used by namespace-aware applications
and these applications should not need be programmed to cope with every
namespace variant, especially if there may be dozens.
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/ 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)
From tyler at infinet.com Thu Sep 16 22:00:44 1999
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun 7 17:15:04 2004
Subject: XML in the real world... Was "Re: Another look at namespaces"
References: <4.1.19990916120701.0249cb80@mail.webgeek.com>
Message-ID: <37E14C81.177ECBD7@infinet.com>
Ann Navarro wrote:
> At 11:43 AM 9/16/99 -0400, Hunter, David wrote:
> >(If I develop an Intranet application, I want to be able to
> >use XHTML without clients having to run out to the W3C site regularly.
> >Ditto for any other XML vocabularies which are defined going forward, from
> >the W3C or anyone else.)
>
> It also should be noted that there's nothing precluding a cache'd copy of
> that "thing" for that Intranet application.
True, but I think all of this misses the point here. Since November 1997 when I started
working with XML, I have never once found any need for a DTD or some other Schema language for
the applications I have written which use XML. For databases, schema's I feel are very
necessary, but I just have not found any real-world use for DTD's or schemas to date other
than as a technical document a programmer can refer to.
Add in what namespaces do to DTD's and Schemas in general and you effectively have no real
reason to produce documents that would be processed by a validating XML Parser.
The one exception I can think of is an abstract element tree like the DOM where you want to
make sure you have a valid document since the DOM itself has no way of enforcing a document
type during the tree building process.
In the case of most applications, they build there own data structures directly from an
event-based XML parser or else from some sort of object-oriented framework which delegates the
events to some sort of abstract element API. If you get an unknown form of element content,
the application can choose how to handle it as it wishes. Whether this element content is
supposed to be there is defined by programmer documentation which may include a DTD as a
reference (such as in the XSLT spec). If expected element content does not occur within the
scope of the containing element being processed, then the application can fill in the default
values as it sees fit.
In the case of internal general entities (if you choose to use them), you can handle all of
that business at the application level as well, therefore eliminating the need for DTD's or
schemas.
In the case of XHTML and this whole debate about 3 namespaces vs. one namespace, in theory the
3 namespaces proposal makes much more sense than having just one namespace. In reality, for
not just software, but average web netizens as well who believe it or not still sometimes like
to code HTML by hand or at least post-edit the content generated from their very poor and
universally incompatible HTML editing tools, having three namespaces just exponentiates the
confusion.
So the fact this list is arguing about document science concepts for a markup language whose
intended audience is virtually anyone on the internet who wants to build a web page, totally
misses the point. We need to ask the question "how does this impact the users of this
wonderful new markup language we are proposing".
To date, I have only seen a handful of comments on this issue and since I write software for
users for financial gain, and not for personal adulation, I ask myself these questions all the
time when I write a new software module that has some end-user interaction associated with it.
Hopefully the W3C is more concerned with creating an XHTML spec of practical use rather than
some piece of art that CS 101 students will reflect on 100 years later as something beautiful
but "never caught on with the masses". What seems like the best solution sometimes is not
always the most satisficing to your real goals.
Tyler Baker
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)
From jesmith at kaon.com Thu Sep 16 21:57:59 1999
From: jesmith at kaon.com (Joshua E. Smith)
Date: Mon Jun 7 17:15:04 2004
Subject: Binary-encoding of XML for communication
In-Reply-To: <002f01bf0036$4e6a8160$85247385@ssel.toshiba.co.jp>
References: <805C62F55FFAD1118D0800805FBB428D02BBFEAB@cc20exch2.mobility.com>
Message-ID: <3.0.1.32.19990916112925.008c3100@tiac.net>
I'm not aware of any such standard (unless you just did something obvious
like use Java serialization on a DOM). However, my experience has been
that gzip (zlib) crunches textual XML amazingly well (thanks to the fact
that most XML documents are full of the same tags over and over and
over...). And expat can turn XML text into a binary representation really
fast. Sometimes, simple tools work very well.
At 08:26 PM 9/16/99 +0900, Shinichiro HAMADA wrote:
>Hello, all.
>
>We are trying to develop a Server/Clients network system with XML. In this
>system, Clients read structured data and send them as XML data to a server.
>
>We estimate too heavy to communicate text-based XML and to decode/encode it
>to/from XML object tree. So we think it's desiable to communicate XML data
>as binary serialized object tree. And it's better that the binary code is
>open format.
>
>If I remeber correctly, such a open binary XML format are discussed among a
>starndard XML community. Is it true? If anyone knew anything about that,
>please tell me.
>
>Thank you in advance.
>
>--
>Shinichiro HAMADA
>TOSHIBA Corp.
>
>
>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)
>
>
>
-Joshua Smith
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)
From paul at prescod.net Thu Sep 16 23:06:50 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun 7 17:15:05 2004
Subject: Another try on groves
Message-ID: <37E1532B.82F3BB03@prescod.net>
Imagine that you are a Mozilla programmer. One day you are trolling
through the XML family of specifications and you notice that RDF and
XLink offer some intriguing possibilities.
RDF allows you to associate, let's say, ratings with components of XML
documents. So you could have a big XML document representing a Slashdot
forum and you could use RDF to hide the articles ranked as trolls. Using
RDF all of this could be done on the client side using sophisticated
Mozilla-built in features. Of course a decent programmer would not
restrict the feature to Slashdot, or to online forums but to any XML
document with ratings described by RDF.
Using XLink you could also allow links to be imposed. These could point
to other documents on the Web that relate to the current conversation.
They could also be annotations by non-slashdot members.
A light comes on. Now you understand what these specifications were
meant to allow.
So you start madly implementing. As you are about a third of the way
through you notice that the RDF and XLink specifications do not
explicitly limit their targets to XML. ANY media type with a fragment
identifier can be described by RDF or linked by XLink. Uh oh. Things
just got a lot more complex. You can now address into PDFs, MPEGs,
ShockWaves and CorelDraw graphics. Of course Mozilla supports those
formats though third party plug-ins. You don't even have the code to
them...the only way to influence them is to improve the plug-in API.
Now you have a choice: you can subvert the intent of the RDF and XLink
specifications by pretending that they only apply to XML or you can step
up to the challenge of implementing the features in a manner that does
not discriminate against non-XML media types. Obviously MPEG movies are
not going to be XML documents in our lifetimes.
If you are in a hurry you might jump to the conclusion that the best way
to address into these media types is either to convert them INTO XML
(perhaps reasonable for PDF) or at least have them expose their
properties as a DOM.
The problem with being in a hurry is that you end up wasting time. You
will waste time here because the impedence mismatch between MPEGs and
the DOM is going to be huge. A frame is not an "element", it has no
"attributes". Now I claim that a frame is an object and that it has
properties. And any idiot knows that objects can be represented in XML
using a variety of techniques but think about the logic of doing it this
way: you are taking a thing that is "logically" an object, expressing it
in terms of a text file format so that another module in the same
process can re-interpret it as logical objects.
The *only good reason* to dumb something down into XML elements and
attributes is to move the information between processes separated by
space, time or incompatibility. Using XML as the "universal API" is
madness because there *is no universal API*. The idea is patently
ridiculous. (some Unix evangelists have claimed that open/read/write is
hte universal interface but actual Unix usage demonstrates that this is
not even close to true...look at the heavy usage of CORBA and IDL in
Unix GUIs)
The term "dumb down" is not an insult against XML or the DOM. After all,
the act of representing something as XML necessarily "dumbs down" the
XML to Unicode characters but that can hardly be considered an insult
against Unicode! Representing Unicode requires a dumbing down into
octets which are dumbed down into bits to be sent across the wire.
All of this dumbing down is great when it is necessary but inconvenient
and inefficient when it is not.
So as a Mozilla programmer your next step is to define a base class for
"linkable objects". Let's call those "nodes." In order to navigate
around these nodes it is useful (some claim necessary...I believe them
but have not verified this for myself) to have the nodes have properties
like "parent", "children", and so forth.
Yes, this is very DOM like but the big difference comes in the next
step: the next step is that the "properties" of these things can be
rich -- not "dumbed down" to elements and attributes. This not only
removes two layers of code (dumbing down and building up) it also
removes a lot of potential for confusion: "the object's principle light
source property is represented by a reference to a principle light
source element which represents a light source object. Go read the
documentation to see how a light source object is represented in our DOM
representation."
Why not represent a "principle light source" property with a property
named "principle light source" and why not let its value be a real
object (not an element) with properties that are also real objects.
Okay, so what else do we need in our "node" ("linkable object")
interface? Well, runtime discoverability of node types and properties is
useful in any language and absolutely required if we are going to expose
our objects in a dynamically typed language like Javascript or DSSSL. So
we need methods that allow us to find out the node's class and property
list.
This base "interface" is known in grove terms as the "intrinsic
properties." They aren't just magical hidden features -- they are
properties just like "principle light source" and "element type name."
There's an important operation we need every pair of nodes to support:
given two node references we need to be able to figure out if they are
to the same node. If we are going to make a list of all opinions about a
particular Slashdot posting then we need to be able to recognize when
multiple links are talking about the same thing. This is why I've harped
in the past, on this list, about object identity. Linking is not going
to work properly unless we figure it out.
Arguably, object identity is the *whole point of groves*. But of course
there is more.
Now consider that some applications work on all XML document types but
many work on only a particular document type. The same holds for COM
objects. The same holds for groves. Some will work with any old grove
(e.g., a hyperlink database) but a renderer will require a particular
set of node types.
Just as we have a schema to allow XML documents in a class to be
consistent we have a schema for groves called a "property set." This can
even be compiled into a header file in a strongly typed programming
language (just like a COM type library or OLE class).
Here are what I consider the crucial points of this discussion:
* existing web technologies will not "work properly" without a data
model for linkable, annotable data. These technologies implicitly depend
upon this model that *does not exist*. Call it a universal data model,
meta data-model, meta, meta, data-model, whatever. It needs to exist.
* near-term software applications will run up against the lack of this
model not in the distant future but in years or months. Arguably they
have *already* run up against the problem of the lack of this model. The
XML information set is a stop-gap for applications that are all XML but
this is supposed to be a hypermedia web -- the stopgap can only hold for
so long.
* there is nothing futuristic about groves. They take some basic ideas
from the information set, add them to some basic ideas from COM/CORBA,
add in a few original ideas specific to the hyperlinking domain and
that's it. Groves only seem abstract because most people are still
confused by and scared of linking applications. The (IMHO) chaotic
development of linking and annotative specifications and software on the
Web is a symptom of this same problem.
Paul Prescod
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)
From mike at DataChannel.com Thu Sep 16 23:31:46 1999
From: mike at DataChannel.com (Mike Dierken)
Date: Mon Jun 7 17:15:05 2004
Subject: Transmitting CGI vars to an XML doc.
Message-ID: <8EAE75D3D142D211A45200A0C99B6023013253CD@ZEUS>
I did something like this a while back that I termed 'Dynamic Entity
References' and here is a write-up:
http://xdev.datachannel.com/press/lounge.html
This may give you more ideas.
Mike
-----Original Message-----
From: Binesh Bannerjee [mailto:binesh@hex21.com]
Sent: Wednesday, August 18, 1999 10:13 AM
To: xml-dev@ic.ac.uk
Subject: Re: Transmitting CGI vars to an XML doc.
On Wed, 18 Aug 1999, Binesh Bannerjee wrote:
> What is the way that people here are using to send CGI parameters
> to an XML driven CGI?
Sorry for the endless clarifications, but I just ... Well, want to clarify.
The way I'm thinking about approaching this is as follows:
CGI request comes into Servlet.
Servlet creates a "CGI_Descriptor" XML doc.
Servlet passes CGI XML doc, Template XML doc, Template XSL doc
to "Processor"
Processor reads Template XML doc (via DOM) replaces CGI vars
[ This is the part that's unclear to me. ]
Processor spawns new processors to handle "Subtemplates" within
template (which follows recursively this same procedure.)
Processor uses XSL to create the output page, and sends
this off to the browser.
My unknowns are, how to represent in the Template XML doc CGI variables,
and how people are handling XML in "subtemplates" that themselves
may need to be processed further...
Am I correct in thinking that adding say a "
Which then I'd write something using the DOM, that traverses the doc
and looks for binesh_plugin, and replaces that node with whatever
it thinks should be there instead... But I'd _hate_ to have to do this
because anything I do with DOM would be opaque to a general XML style
browsers...
Again any help appreciated, thanks...
(BTW, total Unix guy and microsoft-phobe here... So...)
Binesh
* There's nothing wrong with me... http://www.panix.com/~binesh
*
* There's something wrong with the universe. http://www.hex21.com/
*
* CGI/Java Consulting
*
* I know it's all in vain
*
* I know that I'm to blame
*
* I know the purest rain
*
* Won't wash this bloody stain
*
* I know this sickness from inside
*
* Will tear us apart, tear us apart
*
* You're still in my heart tearing apart
*
* Tearing Apart - Siouxsie And The Banshees
*
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)
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)
From ann at webgeek.com Thu Sep 16 23:28:06 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:05 2004
Subject: Another look at namespaces
In-Reply-To: <00bc01bf0076$ed87bca0$1ff96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <4.1.19990916172542.025cd8c0@mail.webgeek.com>
At 03:08 AM 9/17/99 +0800, Rick Jelliffe wrote:
> From: Ann Navarro
>
>>At 02:17 AM 9/17/99 +0800, Rick Jelliffe wrote:
>>
>>>that does
>>>not mean we are accusing the HTML WG of being a conspiracy.
>>
>>No, but you're basically suggesting that we're thick.
>
>Come on, stop making this into some personal thing.
I think I've shown a remarkable degree of restraint over the past few
weeks, in the face of considerable hyperbole and poor assumptions. But I do
object to the assertion that we're somehow out in left field. We disagree,
there's a difference.
>There still has been no justification for it:
What are you doing to do if you get something that finally meets your
definition of "justification"?
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From ken_north at compuserve.com Thu Sep 16 23:19:00 1999
From: ken_north at compuserve.com (Ken North)
Date: Mon Jun 7 17:15:05 2004
Subject: Sybase and XML?
References: <01BF003F.C86030B0@grappa.ito.tu-darmstadt.de>
Message-ID: <006d01bf0089$784e9a40$0b00a8c0@grissom>
Ronald Bourret wrote:
> Do you know of any URLs with technical details? I've poked around the
IBM,
> Microsoft, Sybase, and Informix web sites, but can't find anything
specific
Ron,
1. The Sybase site has some white papers in PDF format. You can find them by
searching on XML.
2. AFAIK, nothing has been published on the Informix site.
3. Microsoft just made its announcement this week. The code name for the
next release of SQL Server is Shiloh, so you might try using that for
further searching.
4. Information isn't freely available because beta testers sign a
non-disclosure agreement. Anything I can post here has to have been publicly
disclosed.
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)
From abrahams at valinet.com Fri Sep 17 00:06:56 1999
From: abrahams at valinet.com (Paul W. Abrahams)
Date: Mon Jun 7 17:15:05 2004
Subject: Unicode surrogate block in XML?
Message-ID: <37E16B3C.1FC56A27@valinet.com>
The XML 1.0 spec explicitly excludes the Unicode surrogate characters
from XML documents (production 2). It now seems, from information
I've picked up on the Unicode web site, that surrogate characters are
likely to play a more important role in the future, since the
available 16-bit characters are almost all used up. (Unicode 2.0 has
18,134 spares but Unicode 3.0 has only 7827 spares. The trend is
clear.)
Is any thought being given in W3C to allowing surrogate characters in
XML documents?
Paul Abrahams
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)
From andrewl at microsoft.com Fri Sep 17 00:04:20 1999
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun 7 17:15:05 2004
Subject: Another look at namespaces
Message-ID: <5BF896CAFE8DD111812400805F1991F712E172C1@RED-MSG-08>
A little more courtesy should be extended to the members of the HTML WG.
The namespaces specification describes a mapping from colonized names to
URIs, and indicates that the function of this is universal identification.
The specification does not require that a namespace correspond to anything
like a schema; but neither does it forbid such correspondence, either
generally or in specific contexts. The specification does not require that
identification indicate semantics, but neither does it forbid it, either
generally or in specific contexts. And so on. No one should take the
silence of the specification on a particular subject as equivalent to either
a recommendation or a proscription. Silence is just ... silence.
On reading the specification, some may wish that it said more, or said what
it does say better, and for the latter, as an editor of the specification, I
apologize.
Some evidently think that the best use of the specification is not the use
to which the HTML WG has put it. These insights are more productive when
shared as a technical discussion on how namespaces should best be used, not
speculations on the intellectual and moral incapacity of the WG; and are
always best if accompanied by the courtesy of remembering that when people
disagree with you, it is not always the sign of some fault in them.
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)
From ann at webgeek.com Fri Sep 17 00:12:17 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:05 2004
Subject: XML in the real world... Was "Re: Another look at
namespaces"
In-Reply-To: <37E14C81.177ECBD7@infinet.com>
References: <4.1.19990916120701.0249cb80@mail.webgeek.com>
Message-ID: <4.1.19990916181124.025d5510@mail.webgeek.com>
At 04:01 PM 9/16/99 -0400, Tyler Baker wrote:
>Ann Navarro wrote:
>
>> At 11:43 AM 9/16/99 -0400, Hunter, David wrote:
>> >(If I develop an Intranet application, I want to be able to
>> >use XHTML without clients having to run out to the W3C site regularly.
>> >Ditto for any other XML vocabularies which are defined going forward, from
>> >the W3C or anyone else.)
>>
>> It also should be noted that there's nothing precluding a cache'd copy of
>> that "thing" for that Intranet application.
>
>True, but I think all of this misses the point here. Since November 1997
>when I started
>working with XML, I have never once found any need for a DTD or some other
>Schema language for
>the applications I have written which use XML.
We need to be careful to remember that when working with Recommendations,
our own personal experiences aren't the only experiences that are
applicable. I personally detest frames, yet they were popular enough to
make it into previous HTML Recs. That I didn't like/need/use them didn't
invalidate their (then) usefulness.
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From paul at prescod.net Fri Sep 17 00:26:16 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun 7 17:15:05 2004
Subject: Another look at namespaces
References: <006101beffba$a2984280$a60a1712@col.w3.org> <14304.11288.712453.705292@localhost.localdomain>
Message-ID: <37E16A98.9235C4@prescod.net>
David Megginson wrote:
>
> 1. An application must be able to determine the general language used
> by (part of) a document.
> 2. An application must be able to determine the specific dialect used
> by (part of) a document.
David, can you please define "general language" and "dialect" in a
manner that I can implement in a computer program? Is "XML" a general
language? Is "XHTML" a dialect? Is "XSLT" a language and "XSLT used with
XSL FOs" a dialect? Please don't appeal to my common sense or intuition
because I have neither and unfortunately neither does my Pentium 233.
> We mustn't make easy tasks difficult for the sake of theoretical
> purity --
It isn't a question of theoretical purity. It's a question of
implementability. According to your model every "language" and "dialect"
becomes a special case because there is no definition of what is a
language and what is a dialect. You can't design a general purpose
processor for mapping dialects into languages or between dialects
because it's all "language" specific. Want to know how HTML dialects are
related? Go read the HTML spec. Want to know how SVG dialects are
related? Go read the SVG spec.
> I know, because we tried to do that over and over again in
> the SGML world, and, well, we're not debating SGML any more, are we?
It seems that we are. Renamed, retargeted and revamped -- and getting
"purer and purer" every day (for better or worse). Compare the design
purity of, let's say CONCUR to that of namespaces (not entirely
unrelated problem domains, BTW). And let's not even get into SHORTREF.
SGML was NOT a purist design -- XML is closer but is still pretty far
away from purity.
Paul Prescod
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)
From andrewl at microsoft.com Fri Sep 17 00:37:46 1999
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun 7 17:15:05 2004
Subject: Binary-encoding of XML for communication
Message-ID: <5BF896CAFE8DD111812400805F1991F712E172C2@RED-MSG-08>
Actually, much XML is transmitted in a binary form today, thanks to the LZ
compression built into modern modems. As Joshua Smith observed, XML
compresses amazingly well (in my tests, many documents compress to between
five and ten percent of their original size). And, as others have observed,
much value in XML comes from the fact that it is text-based.
Before investing in a non-textual equivalent of XML, I recommend carefully
looking at whether and where such a thing is actually needed.
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)
From andrewl at microsoft.com Fri Sep 17 00:39:00 1999
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun 7 17:15:05 2004
Subject: Another look at namespaces
Message-ID: <5BF896CAFE8DD111812400805F1991F712E172C4@RED-MSG-08>
Rick Jeliffe wrote "Andrew Layman's comment that there
are definitional schemas and that these set namespaces is undebated
and can be proved wrong by the simple example of RDF, which
defines a namespace but allows major parts of schemas undefined,..."
I recommend that you return to my original post and look at what I actually
wrote. You might be pleasantly surprised to find that I am both aware of
and support the idea of namespaces which are not defined by schemas. :-)
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)
From david at megginson.com Fri Sep 17 02:09:49 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:05 2004
Subject: Another look at namespaces
In-Reply-To: <000001bf0068$8d5f6020$15a8fea9@w21tp>
References: <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08>
<000001bf0068$8d5f6020$15a8fea9@w21tp>
Message-ID: <14305.20165.688555.834528@localhost.localdomain>
Don Park writes:
> I believe that:
>
> 1. A namespace is empty of meaning beyond being distinguishable from other
> namespaces.
> 2. A name within a namespace is also meaningless beyond being
> distinguishable from other names in the namespace.
> 3. Meaning of a name requires a frame of reference.
I cannot remember Tim Bray's exact wording, but he said something like
"programs can use qualified names they recognize as triggers for
processing behaviour". That (or whatever he actually said) is the
best summary of Namespaces that's come out so far.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From david at megginson.com Fri Sep 17 02:03:55 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:05 2004
Subject: Another look at namespaces
In-Reply-To: <199909161702.NAA11855@hesketh.net>
References: <3.0.5.32.19990916091610.00cc9370@corp.infoseek.com>
<006101beffba$a2984280$a60a1712@col.w3.org>
<199909161702.NAA11855@hesketh.net>
Message-ID: <14305.19804.526873.841691@localhost.localdomain>
Simon St.Laurent writes:
> I don't think anyone's argued hard that three flavors of DTDs was a
> horrible thing, though I know many of us (including, perhaps even Ann)
> would just as soon reduce it to one.
This is actually an important point -- I have found three flavours of
HTML DTD very useful for authoring (in PSGML), but I have not found or
written any processing tools at all that care about which DTD I
happened to use.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From tbray at textuality.com Fri Sep 17 02:35:28 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun 7 17:15:05 2004
Subject: Unicode surrogate block in XML?
Message-ID: <3.0.32.19990916173644.00c55100@pop.intergate.bc.ca>
At 06:12 PM 9/16/99 -0400, Paul W. Abrahams wrote:
>The XML 1.0 spec explicitly excludes the Unicode surrogate characters
>from XML documents (production 2). It now seems, from information
>I've picked up on the Unicode web site, that surrogate characters are
>likely to play a more important role in the future, since the
>available 16-bit characters are almost all used up. (Unicode 2.0 has
>18,134 spares but Unicode 3.0 has only 7827 spares. The trend is
>clear.)
No. Production [2] says
[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF]
| [#xE000-#xFFFD] | [#x10000-#x10FFFF]
This follows the unicode model in allowing 17 planes of 64k characters
each, i.e. about a million characters. For this to work in UTF-16, you
need surrogate pairs. What XML rules out is *characters* whose numeric
value is that of one-half of a surrogate pair. There will never be any
such characters precisely because those values are reserved for use in
surrogate pairs. That's why XML rules them out. -Tim
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)
From simonstl at simonstl.com Fri Sep 17 02:58:11 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:05 2004
Subject: Discourse and Discourtesies
In-Reply-To: <5BF896CAFE8DD111812400805F1991F712E172C1@RED-MSG-08>
Message-ID: <199909170100.VAA32573@hesketh.net>
At 03:05 PM 9/16/99 -0700, Andrew Layman wrote:
>A little more courtesy should be extended to the members of the HTML WG.
Could you please let us know precisely what it is that you're objecting to?
A number of W3C-affiliated folks are griping, but, to be honest, I don't
see any discourtesy, just a large number of serious questions. (Your
message didn't cite any examples.) If anything, I see W3C folk turning back
serious questions with personal reactions and overstated rhetoric that
borders on contempt and ridicule.
While it is unfortunate that a seemingly large number of XML-dev folk
disagree with the work of the HTML WG, I don't see much flamethrowing going
on. Some folks may interpret disagreement as personal attacks, but I can't
see I've seen cause for that lately.
Just curious,
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From terje at in-progress.com Fri Sep 17 05:01:38 1999
From: terje at in-progress.com (Terje Norderhaug)
Date: Mon Jun 7 17:15:06 2004
Subject: XML in the real world... Was "Re: Another look at namespaces"
Message-ID:
At 1:01 PM 9/16/99, Tyler Baker wrote:
>
>True, but I think all of this misses the point here. Since November 1997
>when I started
>working with XML, I have never once found any need for a DTD or some other
>Schema language for
>the applications I have written which use XML. For databases, schema's I
>feel are very
>necessary, but I just have not found any real-world use for DTD's or
>schemas to date other
>than as a technical document a programmer can refer to.
An XML editor can facilitate authoring much better if it has a DTD
available. With a DTD, the editor can provide a sophisticated user
interface that suggests the elements that can be used, where they can be
used, and their attributes. Without a DTD, the author will be required to
specify the names of each element and attribute, making authoring
cumbersome. So DTDs have real world use even if the document can be
processed without.
-- Terje Norderhaug
President & Chief Technologist
Media Design in*Progress
San Diego, California
XML Software for Mac Web Professionals at
Take advantage of XML with Emile, the first XML editor for Mac!
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)
From david at megginson.com Fri Sep 17 03:49:41 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:06 2004
Subject: Another look at namespaces
In-Reply-To: <37E16A98.9235C4@prescod.net>
References: <006101beffba$a2984280$a60a1712@col.w3.org>
<14304.11288.712453.705292@localhost.localdomain>
<37E16A98.9235C4@prescod.net>
Message-ID: <14305.26144.396116.962881@localhost.localdomain>
Paul Prescod writes:
> David Megginson wrote:
> >
> > 1. An application must be able to determine the general language used
> > by (part of) a document.
> > 2. An application must be able to determine the specific dialect used
> > by (part of) a document.
>
> David, can you please define "general language" and "dialect" in a
> manner that I can implement in a computer program?
A language is an arbitrary point in a continuum, discovered
empirically. For example, consider the following:
Marked-up text => SGML => HTML => HTML 4.0 => HTML 4.0 strict
There is a very large set of software that can work with HTML (more or
less interoperably), but considerably less software that works with
SGML in general, and almost nothing that works exclusively with HTML
4.0, much less HTML 4.0 strict. More importantly, there is a
well-defined set of behaviours associated with the software that works
with HTML, and that set of behaviours is generally considered useful
in itself.
The same thing applies in natural languages:
Indo-European => Germanic => English => Canadian => Ontario => Toronto
It's easy but wasteful to make too much of small distinctions, though
it's still important to be able to present them.
> Is "XML" a general language? Is "XHTML" a dialect? Is "XSLT" a
> language and "XSLT used with XSL FOs" a dialect? Please don't
> appeal to my common sense or intuition because I have neither and
> unfortunately neither does my Pentium 233.
It depends on your perspective. Since we're talking about Namespaces
in XML documents, then XML itself is the universe, so you can remove
it from the equation. XSLT and XSL FOs are separate languages that
happen to work well together because they don't really compete (unlike
two natural languages, and more like, say, Algebra and English).
Of course, we won't know this for certain until there are enough
implementations of XSLT and XSL FOs to see how people are using them
-- the proof is in the implementation, not the design.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From tyler at infinet.com Fri Sep 17 06:04:17 1999
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun 7 17:15:06 2004
Subject: XML in the real world... Was "Re: Another look atnamespaces"
References: <4.1.19990916120701.0249cb80@mail.webgeek.com> <4.1.19990916181124.025d5510@mail.webgeek.com>
Message-ID: <37E1BE16.B7CAAD7E@infinet.com>
Ann Navarro wrote:
> At 04:01 PM 9/16/99 -0400, Tyler Baker wrote:
> >Ann Navarro wrote:
> >
> >> At 11:43 AM 9/16/99 -0400, Hunter, David wrote:
> >> >(If I develop an Intranet application, I want to be able to
> >> >use XHTML without clients having to run out to the W3C site regularly.
> >> >Ditto for any other XML vocabularies which are defined going forward, from
> >> >the W3C or anyone else.)
> >>
> >> It also should be noted that there's nothing precluding a cache'd copy of
> >> that "thing" for that Intranet application.
> >
> >True, but I think all of this misses the point here. Since November 1997
> >when I started
> >working with XML, I have never once found any need for a DTD or some other
> >Schema language for
> >the applications I have written which use XML.
>
> We need to be careful to remember that when working with Recommendations,
> our own personal experiences aren't the only experiences that are
> applicable. I personally detest frames, yet they were popular enough to
> make it into previous HTML Recs. That I didn't like/need/use them didn't
> invalidate their (then) usefulness.
Comparing frames to schemas is like comparing apples to oranges. I don't mind a
spec having lots of unnecessarily complex and perhaps generally useless features
so long as they are not a prerequisite for accomplishing simple tasks at both the
software level as well as the user level. "Namespaces in XML" is an add on to
XHTML which effectively adds a complex and generally useless feature (as currently
defined) that also happens to be a prerequisite to getting anything simple
accomplished.
For example, while working on an XML parser package a while back, I was
considering implementing support for XSchema as I found DTD's to not do too well
out of a document context. But then I started thinking "Will anyone ever need XML
Schemas in the first place". As I said before, other than for the sake of having a
language for expressing a data format in programmer documentation (like with
EBNF), what does a schema do at the software level other than for enforcing rules
in an editor? I look at XML as being more of a protocol than anything of
persistent value even though I have used XML for both persistence and as a
serialization protocol in the same application (a testament to XML 1.0 being
simple enough to be useful for all kinds of tasks).
So with respect to XHTML, again I beg the question, why do we need three HTML
specs when most HTML parsers are some hack job that try and handle everything that
can possibly be thrown at it?. When writing one of these very forgiving parsers,
falling back on some DTD for validation will get you absolutely nothing.
So even though in principle 3 XHTML namespaces might make more sense than having
just one, what does this actually buy you at the software level (in other words
what does it buy for the poor souls at MS and AOL who have to implement all of
this stuff in the next generation of web browsers), what does it buy professional
webmasters who now have to not only create specially tailored web sites for
Navigator and Internet Explorer, but now may have to create web sites for these
two browsers times three for each namespace, and what does it buy end-users who
will need to take a bottle of Advil whenever they first hear the word "Namespace"?
Remember that HTML really took off because it was simple and just about any novice
computer user could whip up a web page in no time flat. What is the purpose of
making things more complicated if they serve no useful purpose for the future. I
mean, how are we enhancing the user experience of HTML in web browsers and other
applications with having namespaces in XHTML in the first place? Having the
"Namespaces in XML" spec fall into XHTML is about the worse thing you could ever
do if you want the next generation of HTML to be usable by anyone other than
experienced professional programmers. Even though I really could care less about
HTML right now for the applications I write at the moment, I just don't like
seeing an entire generation of web developers and web users have to deal with an
HTML spec that has a much higher learning curve than necessary.
Regards,
Tyler
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)
From tyler at infinet.com Fri Sep 17 06:22:47 1999
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun 7 17:15:06 2004
Subject: XML in the real world... Was "Re: Another look at namespaces"
References:
Message-ID: <37E1C268.6ADC9810@infinet.com>
Terje Norderhaug wrote:
> At 1:01 PM 9/16/99, Tyler Baker wrote:
> >
> >True, but I think all of this misses the point here. Since November 1997
> >when I started
> >working with XML, I have never once found any need for a DTD or some other
> >Schema language for
> >the applications I have written which use XML. For databases, schema's I
> >feel are very
> >necessary, but I just have not found any real-world use for DTD's or
> >schemas to date other
> >than as a technical document a programmer can refer to.
>
> An XML editor can facilitate authoring much better if it has a DTD
> available. With a DTD, the editor can provide a sophisticated user
> interface that suggests the elements that can be used, where they can be
> used, and their attributes. Without a DTD, the author will be required to
> specify the names of each element and attribute, making authoring
> cumbersome. So DTDs have real world use even if the document can be
> processed without.
XML is used as a base for all sorts of document and data formats. An editor
which simply displays a tree diagram of XML content does not buy you much. HTML
editors used to do this and still do cause some people do like to do things by
hand, but really most HTML editors are WYSIWYG in nature now. XML content is
generally and almost exclusively created by a script or software that uses XML
as either a document format or else as a serialization protocol for some type
of object. In both instances, the software almost always writes out elements
directly to a stream.
The point is, if you want to do redundant validation at the parser level and
then at the application level, then you are always free to do so. Either way,
until we have machines that actually think you are not gonna be able to just
take some abstract piece of content that does not have a particular software
module associated with it and do anything interesting with it. Most
high-performance HTML parsers I am aware of just parse the data directly into
an object tree and enforce the rules of HTML directly rather than fallback on a
DTD.
So again what do 3 namespaces buy you that one namespace does not even if you
have 3 different DTD's for XHTML?
Tyler
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)
From tgraham at mulberrytech.com Fri Sep 17 07:13:57 1999
From: tgraham at mulberrytech.com (Tony Graham)
Date: Mon Jun 7 17:15:06 2004
Subject: Unicode surrogate block in XML?
In-Reply-To: <37E16B3C.1FC56A27@valinet.com>
References: <37E16B3C.1FC56A27@valinet.com>
Message-ID: <14305.52871.340000.400547@menteith.com>
At 16 Sep 1999 18:12 -0400, Paul W. Abrahams wrote:
> The XML 1.0 spec explicitly excludes the Unicode surrogate characters
> from XML documents (production 2). It now seems, from information
> I've picked up on the Unicode web site, that surrogate characters are
> likely to play a more important role in the future, since the
> available 16-bit characters are almost all used up. (Unicode 2.0 has
> 18,134 spares but Unicode 3.0 has only 7827 spares. The trend is
> clear.)
>
> Is any thought being given in W3C to allowing surrogate characters in
> XML documents?
The code values from the Surrogate block (soon to be the High
Surrogates, High Private Use Surrogates, and Low Surrogates) are not
allowed in XML documents, but the characters that you reference with
the two parts of a Surrogate Pair are definitely allowed.
The characters that you can address with a Surrogate Pair are in the
range #x10000 to #x10FFFF. In Unicode terminology, this is the
Unicode Scalar Value of the Surrogate Pair.
Production 2 from the XML Recommendation shows that these are legal
characters:
[2] Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD]
| [#x10000-#x10FFFF]
In a UTF-16 encoded document, you can use the code values from the
Surrogate block to refer to these characters. It would be an error if,
for example, you used an unpaired Surrogate code value, but any UTF-16
application is going to complain about or ignore an unpaired
surrogate.
In a UTF-8 encoded document, you can refer to the characters in the
range #x10000 to #x10FFFF using a four-byte sequence that has no
relationship to the code values in the Surrogate block.
In UCS-4 (or the new UTF-32) you can directly represent characters in
the range #x10000 to #x10FFFF.
In any XML document, you can make numeric references to any Unicode
character in the range #x10000 to #x10FFFF (as well as to any other
legal character number). These references are independent of the
encoding used in the XML document.
#x10000 is the first code value outside the Basic Multilingual Plane
(the ISO/IEC 10646 term for the characters in the range #x0 to
#xFFFF). "𐀀" is the hexadecimal numeric reference for this
code value.
The sequence of #xD800 #xDC00 is the two Surrogate code values that
address #x10000. That four-byte sequence may occur in a UTF-16
encoded file to represent #x10000. In contrast, "��" in
an XML document is two illegal character references in a row.
Regards,
Tony Graham
======================================================================
Tony Graham mailto:tgraham@mulberrytech.com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9632
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================
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)
From shinichiro.hamada at toshiba.co.jp Fri Sep 17 09:23:01 1999
From: shinichiro.hamada at toshiba.co.jp (Shinichiro HAMADA)
Date: Mon Jun 7 17:15:06 2004
Subject: Binary-encoding of XML for communication
References: <805C62F55FFAD1118D0800805FBB428D02BBFEAB@cc20exch2.mobility.com> <3.0.5.32.19990916101657.00a6de40@corp.infoseek.com>
Message-ID: <004f01bf00dd$f7cad1e0$85247385@ssel.toshiba.co.jp>
Thank you for all comments!
We feel severe about CPU load of the server rather than communication traffic.
So we are looking for codes easy to decode into object tree. In addition to it,
we also hope to keep system openness.
All your comments are very helpful for us.
1 HTTP 1.1 "content-coding"
2 Use SAX
3 LZ Compression
Thank you very much.
--
Shinichiro HAMADA
TOSHIBA Corp.
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)
From ricko at allette.com.au Fri Sep 17 09:44:07 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:06 2004
Subject: Another look at namespaces
Message-ID: <009301bf00e1$4b8cbf20$3bf96d8c@NT.JELLIFFE.COM.AU>
From: Andrew Layman
>Rick Jeliffe wrote "Andrew Layman's comment that there
>are definitional schemas and that these set namespaces is undebated
>and can be proved wrong by the simple example of RDF, which
>defines a namespace but allows major parts of schemas undefined,..."
>
>I recommend that you return to my original post and look at what I
actually
>wrote. You might be pleasantly surprised to find that I am both aware
of
>and support the idea of namespaces which are not defined by schemas.
:-)
I think second point in that posting is well-made, that "There is
nothing in
the namespaces specification that requires that all the elements in a
document
come from the same namespace". I don't think that is a contentious
issue.
But it is the first point, that I don't see:
"If indeed there are separate languages, where the elements in one
require different processing (such as different validation) from
elements in
another, then the distinct elements of each should be distinguished by
different namespaces."
This says that a schema determines the namespace. A change in content
model
requires a change in namespace; the namespace URI is a new doctype
declaration
with attribute syntax and different combining rules. ( I agree that
different meanings "should" be distinguished by different namespaces,
otherwise the whole
use of namespaces is subverted, but to say that different validation
requires
different namespaces goes much to far. A schema uses names in spaces;
a document uses names in spaces; a schema does not create a namespace
and
a document does not create a namespace (at the moment, nothing formally
creates/defines a namespace, in the same way that nothing defines a
URI: the URI if syntactically correct is useable for a purpose or
unuseable.)
It follows from Andrew's second point that if I want to use and
include in it my own element then I cannot use any of the
namespaces provided by XHTML. These namespaces invoke particular
DTDs, and these DTDs have closed content models (if they were open,
we would only need one namespace).
This contrasts with the view that we can derives the items in a
namespace
by looking at all the schemas and documents which invoke that namespace.
In the absense of a namespace definition language, containing just a
simple
list, that there is
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)
From donpark at docuverse.com Fri Sep 17 11:04:42 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun 7 17:15:06 2004
Subject: Discourse and Discourtesies
In-Reply-To: <199909170100.VAA32573@hesketh.net>
Message-ID: <000501bf00ec$33342340$74bbfea9@w21tp>
Frankly, I like it like this. It feels like New York without the smell.
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
From donpark at docuverse.com Fri Sep 17 11:04:32 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun 7 17:15:06 2004
Subject: Another try on groves
In-Reply-To: <37E1532B.82F3BB03@prescod.net>
Message-ID: <000301bf00ec$2ff60f40$74bbfea9@w21tp>
Paul,
Thanks for the excellent article. I am starting to see the light (although
it could just be that I left the kitchen light on :).
Elements and attributes are indeed crude and cumbersome to use. Script
languages like JavaScript relieves some of the pain but most of the work so
far has been on making HTML easier to work with and support for other
document models is sadly lacking.
I do have great hope for the XML Data Binding specification (see below for
link) which does address half of the issues you raised. Concerns I have
with XML Data Binding specification are a) it is a Java-only solution, and
b) it doesn't exist yet.
I also agree that node references would be far easier to work with if they
behaved exactly like the referenced objects. But then it is just
application of the Proxy design pattern with node identity requirement
thrown in.
At this point, I see the Grove concept as not something new but very old,
practical, and obvious, at least to me, described in abstract ways. Its
very strength, general applicability, is probably the very reason why people
who understand it feel that it must be described abstractly.
I do like the Grove concept and now feel that it will have its day in the
Sun (sorry, JavaSoft then). However, I believe the patient must feel the
pain, acutely and repeatedly, before the doctor can prescribe the cure. DOM
will be used and then abandoned later for something better when the pain
becomes too much.
Best,
Don Park
Docuverse
References:
XML Data Binding specification:
http://www.javasoft.com/aboutJava/communityprocess/jsr/jsr_031_xmld.html
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)
From steven.livingstone at scotent.co.uk Fri Sep 17 11:18:49 1999
From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM)
Date: Mon Jun 7 17:15:06 2004
Subject: SOAP
Message-ID: <8DCB90532FF7D211B34400805FD488536F61AC@SENMAIL3>
I have created a mailing list for SOAP (Simple Object Access Protocol) for
discussions relating to the recent specification sent to the IETF at
http://search.ietf.org/internet-drafts/draft-box-http-soap-00.txt
Please send a blannk email to rpc-soap-subscribe@onelist.com if you wish to
join.
Thanks for your time -
Steven
Steven Livingstone - http://www.deltabiz.com
07771 957 280 or +447771957280
Author -
Professional Site Server 3, Wrox Press
http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002696
Professional Site Server 3.0 Commerce Edition, Wrox Press
http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002505
President, AIP Scotland.
ceo@citix.com
http://www.citix.com
Join Association of Internet Professionals - http://www.citix.com/aip
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)
From francis at redrice.com Fri Sep 17 11:28:06 1999
From: francis at redrice.com (Francis Norton)
Date: Mon Jun 7 17:15:06 2004
Subject: Another try on groves
References: <37E1532B.82F3BB03@prescod.net>
Message-ID: <37E20A5C.75E79B93@redrice.com>
Thank you Paul.
No disrespect to the more political discussions on XML-DEV, which I
appreciate are inspired by deep feelings about serious issues, but I'd
just like to say that this post is the kind of informative and
enlightening gem that makes it worth plowing through all the traffic.
Now that I have some feeling for the rationale behind Groves, I'd be
very interested in knowing what this might mean for implementations.
Could one come up with a language independent API like the DOM, to which
Grove compliant APIs would conform? Presumably there is more complexity
in that the DOM has a closed set of underlying object types whereas each
Grove interface would would have different underlying object types. In
Java terms, would this be an interface (a totally abstract class which
guarantees a core functionality in any object which implements it)? Has
anyone in fact built CORBA IDL or a Java interface defining the Grove
API, or am I coming in at the wrong level?
Francis.
Paul Prescod wrote:
[ a compelling illustration and explanation of Groves ]
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)
From davidc at nag.co.uk Fri Sep 17 13:11:50 1999
From: davidc at nag.co.uk (David Carlisle)
Date: Mon Jun 7 17:15:06 2004
Subject: XML in the real world... Was "Re: Another look at namespaces"
Message-ID: <199909171111.MAA14708@nag.co.uk>
Ann said
> We need to be careful to remember that when working with Recommendations,
> our own personal experiences aren't the only experiences that are
> applicable.
True, but personal experience is nevertheless a useful guide.
Given that it is (in my experience) so much more inconvenient to
use a namespace aware application (such as xslt, which is currently the
most common namespace aware application) with XHTML using multiple
namespaces, I have to ask, has _anyone_ who is proposing that this is a
good idea actually tried using the multiple namespace approach in
practice?
If you are using an application that ignores the namespace declaration
then arguing the finer points of which is the more correct namespace
model is an interesting, but not very practical, exercise.
My fear is that as the extra effort to use multiple namespaces will be
too great for most people, the actual result of an XHTML with 3
namespaces will be that the vast majority of XHTML documents will
not specify a namespace at all, thus making it easier to write
stylesheets etc. (eg ...) This will put
a broad class of XHTML documents into the null namespace which will
totally break the whole intention of namespaces that would allow
tools to recognise XHTML elements as XHTML rather than some other
XML element that just happens to have the same name.
David
PS
Ann, I know (from personal experience:-) what it is like to be upholding
an official line in the face of multiple complaints on a public list.
I admire the way in which you've kept your calm, and managed to respond
to most of the incoming flood.
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)
From tyler at infinet.com Fri Sep 17 14:25:25 1999
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun 7 17:15:06 2004
Subject: XML in the real world... Was "Re: Another look at namespaces"
References: <199909171111.MAA14708@nag.co.uk>
Message-ID: <37E23365.9E9F1104@infinet.com>
David Carlisle wrote:
> My fear is that as the extra effort to use multiple namespaces will be
> too great for most people, the actual result of an XHTML with 3
> namespaces will be that the vast majority of XHTML documents will
> not specify a namespace at all, thus making it easier to write
> stylesheets etc. (eg ...) This will put
> a broad class of XHTML documents into the null namespace which will
> totally break the whole intention of namespaces that would allow
> tools to recognise XHTML elements as XHTML rather than some other
> XML element that just happens to have the same name.
I think that this is what will end up happening in the end. A long time ago in a galaxy far
far away when I was working with XSL, I argued that "Namespaces in XML" will probably end up
being completely unused by webmasters and the like who are after all the intended audience for
XSL (now more specifically known as XSLT). I do feel that namespaces of some sort will be
necessary for XML, but that ideal is far from what the W3C recommendation "Namespaces in XML"
actually is. Until a decent usable "Namespaces in XML" recommendation comes out (which is
unlikely but there is always hope) then developers like myself will use our own custom
solutions (I have one now which works just great) for dealing with the namespaces issue in our
applications. Unfortunately, those who deal with WWW content almost exclusively in their jobs,
will be forced to deal with the myriad of problems "Namespaces in XML" brings to XHTML. Even
if XHTML were to have just one namespace, "Namespaces in XML" really mucks things up for what
I always thought HTML was supposed to be in that it is a presentation format.
> David
>
> PS
> Ann, I know (from personal experience:-) what it is like to be upholding
> an official line in the face of multiple complaints on a public list.
> I admire the way in which you've kept your calm, and managed to respond
> to most of the incoming flood.
Though I don't agree with what much of Ann has said, I do respect that she at least takes the
time and energy to argue the points of the HTML WG rather than take the usual W3C line of
deafening silence on issues until it is too late. Also, the fact that 99% of the posts on this
list aside from Ann's are from men who need to get out more (including myself) makes it all
the more encouraging to see someone like Ann challenge the incoming flood of testosterone that
swamps this mailing list (-:
Tyler
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)
From david at megginson.com Fri Sep 17 14:30:23 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:07 2004
Subject: XML in the real world... Was "Re: Another look at namespaces"
In-Reply-To: <199909171111.MAA14708@nag.co.uk>
References: <199909171111.MAA14708@nag.co.uk>
Message-ID: <14305.64593.302542.455403@localhost.localdomain>
David Carlisle writes:
> True, but personal experience is nevertheless a useful guide.
> Given that it is (in my experience) so much more inconvenient to
> use a namespace aware application (such as xslt, which is currently the
> most common namespace aware application) with XHTML using multiple
> namespaces, I have to ask, has _anyone_ who is proposing that this is a
> good idea actually tried using the multiple namespace approach in
> practice?
I can answer the second part -- I don't think that it's a good idea,
but I have tried it in practice. Because RDF changed its Namespace
URI at the last minute when it went to REC, there are major deployed
RDF document bases (especially RPMFind and DMOZ) that use still the
wrong Namespace URI for RDF, and cannot easily change to the correct
URI now because they're trapped by deployed software.
In two separate projects, I tried implementing support for the legacy
(incorrect) Namespace URI, and doing so was trickier than I expected,
because it complicates the simple hashing schemes that are necessary
to process Namespace-qualified elements efficiently. For now, I've
decided to support only the correct RDF-Syntax Namespace URI (the one
in the final REC), but I don't imagine that DMOZ or RPMFind will be
able to become conformant any time soon because they have extremely
large user bases with the old Namespace URI hard-coded in their
software.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From timbl at w3.org Fri Sep 17 14:44:35 1999
From: timbl at w3.org (Tim Berners-Lee)
Date: Mon Jun 7 17:15:07 2004
Subject: Binary-encoding of XML for communication
Message-ID: <01de01bf010a$be84d3e0$a60a1712@col.w3.org>
The WAP Binary XML Encoding Specification was submitted to the W3C
http://www.w3.org/Submission/1999/07/
by IBM, Ericsson, Motorola and Phone.com
Dan Connolly's comments on it to put it in perspective of the W3C and XML
are at
http://www.w3.org/Submission/1999/07/Comment
(This does *not* imply any endorsement by W3C in any way nor that is
is on any path to becoming a Recommendation.)
I understand that in the mobile area there is a strong need seen for binary
XML.
I also understand that this specification is not a generic encoding system
for
any XML document - but clearly this problem and some that Dan identifies may
not prevent some of the ideas in the spec being used for a general standard.
I know it is nice to stick with text (and compression if necessary) but if
binary XML
is going to happen anyway, would it not be wise for the XML community to be
involved
so as to ensure that it was absolutely equivalent to XML+NS?
Tim BL
-----Original Message-----
From: Shinichiro HAMADA
To: - XML-Dev
Date: Thursday, September 16, 1999 7:29 AM
Subject: Binary-encoding of XML for communication
>Hello, all.
>
>We are trying to develop a Server/Clients network system with XML. In this
>system, Clients read structured data and send them as XML data to a server.
>
>We estimate too heavy to communicate text-based XML and to decode/encode it
>to/from XML object tree. So we think it's desiable to communicate XML data
>as binary serialized object tree. And it's better that the binary code is
>open format.
>
>If I remeber correctly, such a open binary XML format are discussed among a
>starndard XML community. Is it true? If anyone knew anything about that,
>please tell me.
>
>Thank you in advance.
>
>--
>Shinichiro HAMADA
>TOSHIBA Corp.
>
>
>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)
>
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)
From paul at prescod.net Fri Sep 17 14:47:29 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun 7 17:15:07 2004
Subject: Another look at namespaces
References: <006801bf0068$fcdb9130$1ff96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <37E2357C.FDAD0C55@prescod.net>
Rick Jelliffe wrote:
>
> It seems clear that the HTML team have some mental concept of namespaces
> which exists independently of what the W3C specification actually
> allows.
I think that you are putting the blame in the wrong place. A quick
perusal of this forum suggests that the namespace editors disagree on
what the namespace specification "really means". It seems to me that the
specification has proven too general, too flexible and has been shown to
depend too much on mystical shared understanding of a "reasonable
namespace" that turns out not to be shared.
> If a W3C specs can be utterly overturned in such a way, what is their
> value?
There is nothing in the HTML specification that violates the text of the
XML namespaces specification. If you are going to say that it violates
the "spirit" of the specification then we are back where we started.
Paul Prescod
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)
From paul at prescod.net Fri Sep 17 14:57:26 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun 7 17:15:07 2004
Subject: More than three namespaces for XHTML? (was Re: What XHTML should do with namespaces)
References: <00c101bf0079$362e4cb0$1ff96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <37E23992.32795F94@prescod.net>
Rick Jelliffe wrote:
>
> Actually, it is an issue: if namespaces are to be taken from DTD, then
> every different possible combination of modularized HTML has its own
> effective DTD and will therefore need its own namespace.
>
> So we are not talking about 3 namespaces for XHTML, but potentially
> dozens!
That is not true. If schemas are paramaterizable then we can have one
namespace per schema but still have only a few namespaces. In a
programming language every function has a name, not every possible
combinations of functions:
add( multiply(1,2),multiply(3,4))
not
addmultiplymultiply(1,2,3,4)
Paul Prescod
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)
From paul at prescod.net Fri Sep 17 14:58:28 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun 7 17:15:07 2004
Subject: XML in the real world... Was "Re: Another look at namespaces"
References: <4.1.19990916120701.0249cb80@mail.webgeek.com> <37E14C81.177ECBD7@infinet.com>
Message-ID: <37E23614.E477FEF0@prescod.net>
Tyler Baker wrote:
>
>...
> In the case of most applications, they build there own data structures directly from an
> event-based XML parser or else from some sort of object-oriented framework which delegates the
> events to some sort of abstract element API. If you get an unknown form of element content,
> the application can choose how to handle it as it wishes. Whether this element content is
> supposed to be there is defined by programmer documentation which may include a DTD as a
> reference (such as in the XSLT spec). If expected element content does not occur within the
> scope of the containing element being processed, then the application can fill in the default
> values as it sees fit.
Part of the zen of SGML (inherited by XML) is that standards exist to
protect end users from programmers.
If the definitive *executable* specification for an interchange language
is a software product then the that product's vendor essentially owns
that language. So for instance there is an open specification for "RTF"
but there is no such thing as an RTF "validator" so the definitive
specification for what is or is not valid RTF is Word for Windows. End
users that want to check an RTF document's conformance do so by pumping
it through Word. This puts every competitor to Microsoft at a
disadvantage and that in turn hurts end users. HTML has the same
problem. XHTML is trying to move away from that.
On the other hand, the definitive executable specification (validator)
for Docbook is the DTD and Docbook producing software can be easily
tested for conformance using neutral (and free) third party tools. One
could imagine a world in which there were hundreds of "hand-coded"
validators for RTF, HTML (there are!), and every other language but once
you've written a few of these you come to think: "wouldn't it be better
if there was a generalized way to do that."
Paul Prescod
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)
From timbl at w3.org Fri Sep 17 15:20:34 1999
From: timbl at w3.org (Tim Berners-Lee)
Date: Mon Jun 7 17:15:07 2004
Subject: Another look at namespaces
Message-ID: <01ec01bf010f$2b389950$a60a1712@col.w3.org>
-----Original Message-----
From: Tim Bray
To: XML-DEV
Date: Thursday, September 16, 1999 12:46 PM
Subject: RE: Another look at namespaces
>At 08:30 AM 9/16/99 -0700, Andrew Layman wrote:
>>With all due respect to Simon St. Laurent, I believe that Tim Berners-Lee
>>was correctly precise when he wrote "the document corresponding to the
>>namespace URI becomes
>>the place where the namespace-author can put *definitive*
>>information about the intent of the namespace."
>
>I and many others disagree, for reasons best expressed in Jon Bosak's
>summary of the issues. Among other things, I don't believe that most
>interesting namespaces *have* definitive information, but have semantics
>that are communicated via some messy combination of schemas, stylesheets,
>prose documentation, and running code.
We either have a different use of words or a very serious
problem. Whereas with natural langauge, meanings change and
grow and everyone has slightly different associations with a word,
in computer languages we need to build on top of XML we need
to have the ability to define meaning precicely in terms of
other existing languages.
If you believe that "HTML 4.0" specification - and a schema for XHTML -
can decied that cannot occur in
then do you not grant
th ewriters of the spec the right to make that definitiove assertion (in
prose
or schema) whatever code someone may or may not write to produce or
parse inside
>>While there are many processes that can be applied to a document, and
>>correspondingly many specifications of those processes, there can be, for
a
>>given term in a namespace, at most one correct *definition*.
>
>I disagree, I think this is a strong and surprising claim, and I would
>like to see some real-world supporting evidence.
We are designing this, not investigating it as a natural phenomenon.
This is my understanding of the history of for example RDF and namespaces.
The RDF M&S working group decided it needed a way
for system designers to define new vacabularies for new data models.
They realized that while using XML was something they had been asked to do,
they would need a way of creating new modules of meaning.
The XML working group then explainted that they were producing that
functionality in XML, and so (as with atomic data types) the RDF
group decided to simply hang of teh XML namespace functionality.
This implies taht the meaning of an RDF property (conveyed by an XML
element)
is defined by the namepsace it is in. My assumption - in which I don't
think I was alone - was that this meaning could be (either of course
programmed strighht into a specific application) or information about it
could be put into the schema. The RDF spec, indeed, defines the
relationship between the name and an element of the schema (one
of the bits which needs to be tracked byeween xml and rdf schemas)
I had assumed that the xml schema work would allow definitive information
about content models to be put into the xml schema.
My understanding was also that because one document can contain
information form more than one language, that one schema document,
optionally available at the namespace URI, would contain both
xml-schema language and rdf-schema language.
This is IMHO a very nice arrangement in fact.
Perhaps perception of it is clouded bythe fact that XML 1.0 doesn't mention
namespaces at all, and XML NS does not mention schemas at all.
In other words, the specs -- having to only refer backwards in time --
have not been good at pointing to how the future architecure will fit
together.
Tim BL
in no official capacity.
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)
From ken at bitsko.slc.ut.us Fri Sep 17 15:24:14 1999
From: ken at bitsko.slc.ut.us (Ken MacLeod)
Date: Mon Jun 7 17:15:07 2004
Subject: Another try on groves
In-Reply-To: Francis Norton's message of "Fri, 17 Sep 1999 10:31:08 +0100"
References: <37E1532B.82F3BB03@prescod.net> <37E20A5C.75E79B93@redrice.com>
Message-ID:
Francis Norton writes:
> Now that I have some feeling for the rationale behind Groves, I'd be
> very interested in knowing what this might mean for implementations.
>
> Could one come up with a language independent API like the DOM, to
> which Grove compliant APIs would conform? Presumably there is more
> complexity in that the DOM has a closed set of underlying object
> types whereas each Grove interface would would have different
> underlying object types. In Java terms, would this be an interface
> (a totally abstract class which guarantees a core functionality in
> any object which implements it)? Has anyone in fact built CORBA IDL
> or a Java interface defining the Grove API, or am I coming in at the
> wrong level?
I'd like to believe you're coming in at the wrong level. Many
languages have built-in syntax to access ``members of objects'' or
``fields of records'' that can often be applied to accessing
``properties of nodes''. In this case, the grove API is the
language's native syntax.
Where native syntax is not applicable, groves most closely resemble
container classes (dictionaries, mappings, hash tables; lists, arrays,
sequences). Again, a language's standard container class interface or
protocol can be used.
--
Ken MacLeod
ken@bitsko.slc.ut.us
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)
From david at megginson.com Fri Sep 17 15:28:25 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:07 2004
Subject: XML in the real world... Was "Re: Another look at namespaces"
In-Reply-To: <37E23614.E477FEF0@prescod.net>
References: <4.1.19990916120701.0249cb80@mail.webgeek.com>
<37E14C81.177ECBD7@infinet.com>
<37E23614.E477FEF0@prescod.net>
Message-ID: <14306.2524.155954.17889@localhost.localdomain>
Paul Prescod writes:
> Part of the zen of SGML (inherited by XML) is that standards exist
> to protect end users from programmers.
Unfortunately, standards can end up protecting end users from
programmers so effectively that the end users end up with no
off-the-shelf software: that's why it's a good idea for standards
never to go more than one step ahead of current practice.
Remember, the main goals of computer standards are interoperability
and shared development cost. Many SGML (or CORBA, or what-have-you)
consulting shops rely on exactly the opposite: they make their money
by developing expensive, customized solutions that are only marginally
interoperable, while holding the standards flag over the poor
customer's eyes.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From ann at webgeek.com Fri Sep 17 15:32:10 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:07 2004
Subject: XML in the real world... Was "Re: Another look
atnamespaces"
In-Reply-To: <37E1BE16.B7CAAD7E@infinet.com>
References: <4.1.19990916120701.0249cb80@mail.webgeek.com>
<4.1.19990916181124.025d5510@mail.webgeek.com>
Message-ID: <4.1.19990917092914.02187680@mail.webgeek.com>
At 12:05 AM 9/17/99 -0400, Tyler Baker wrote:
>
>So with respect to XHTML, again I beg the question, why do we need three HTML
>specs when most HTML parsers are some hack job that try and handle
>everything that
>can possibly be thrown at it?. When writing one of these very forgiving
>parsers,
>falling back on some DTD for validation will get you absolutely nothing.
For current HTML parsers, you need exactly *zero* namespaces. They aren't
aware of them. They ignore them. (The same could be said for DTDs on the
rendering side of things, though authoring is greatly aided by their
inclusion).
There is no learning curve in regards to namespaces for the developer of
XHTML documents that will be served on today's Internet as text/html. Zero.
None.
Since XHTML is also XML, namespaces may be used there, which is why we
currently have:
>So even though in principle 3 XHTML namespaces might make more sense than
having just one
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From James.Anderson at mecomnet.de Fri Sep 17 15:39:02 1999
From: James.Anderson at mecomnet.de (james anderson)
Date: Mon Jun 7 17:15:07 2004
Subject: Another look at namespaces
References: <5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08>
<000001bf0068$8d5f6020$15a8fea9@w21tp> <14305.20165.688555.834528@localhost.localdomain>
Message-ID: <37E23B93.55EAD264@mecomnet.de>
David Megginson wrote:
>
>
> I cannot remember Tim Bray's exact wording, but he said something like
> "programs can use qualified names they recognize as triggers for
> processing behaviour". That (or whatever he actually said) is the
> best summary of Namespaces that's come out so far.
Perhaps his exact wording is to be preferred. The stated summary conflates the
identity of the name with the mechanism used to ensure and/or establish that
identity.
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)
From ann at webgeek.com Fri Sep 17 15:42:07 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:07 2004
Subject: XML in the real world... Was "Re: Another look at
namespaces"
In-Reply-To: <199909171111.MAA14708@nag.co.uk>
Message-ID: <4.1.19990917094025.0218f320@mail.webgeek.com>
At 12:11 PM 9/17/99 +0100, David Carlisle wrote:
>Ann, I know (from personal experience:-) what it is like to be upholding
>an official line in the face of multiple complaints on a public list.
>I admire the way in which you've kept your calm, and managed to respond
>to most of the incoming flood.
While it may be the "official" line, it is indeed one I firmly believe in,
which I suppose makes it a bit easier.
Best,
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From david at megginson.com Fri Sep 17 15:44:25 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:07 2004
Subject: Schemas considered dangerous (was Re: Another look at namespaces)
In-Reply-To: <01ec01bf010f$2b389950$a60a1712@col.w3.org>
References: <01ec01bf010f$2b389950$a60a1712@col.w3.org>
Message-ID: <14306.3491.65052.793942@localhost.localdomain>
Tim Berners-Lee writes:
> Perhaps perception of it is clouded bythe fact that XML 1.0 doesn't
> mention namespaces at all, and XML NS does not mention schemas at
> all. In other words, the specs -- having to only refer backwards
> in time -- have not been good at pointing to how the future
> architecure will fit together.
There's also the critically-important point that most programming
languages (such as C++ and Java) do the equivalent of schema
processing at compile time (where it's secure and not time-critical),
while XML processors will have to do it at run time. That means that
there are a few potentially-nasty problems:
1. The burdon of determining inheritance and class relationships falls
on the processor, which has to repeat it for each cycle.
2. Processing time is not predictable, since schemas can reference
other schemas to an unknown depth.
3. Processing is not secure, since schemas will likely be able to
refer to schemas at other sites.
For example of the third problem (which is the most serious), let's
imagine that I have the following document:
Tim Berners-Lee
David Megginson
We'll have the new product ready next month: please remember
that this is confidential.
Now, my 'memo' schema says that it is derived from a 'memo' schema
hosted at the W3C site:
http://www.megginson.com/ns/memo/
is a kind of
http://www.w3.org/schemas/memo#
Assume that the schema at the W3C site has the schema equivalent of
the following DTD construction:
That means that, by default, my memo is confidential. Now, what if
someone cracks the W3C's Web site (not mine), and changes this to the
equivalent of
I write my memo, send it to my document system, and it automatically
displays it on my public Web site. Ouch!
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From ann at webgeek.com Fri Sep 17 15:46:03 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:07 2004
Subject: XML in the real world... Was "Re: Another look at
namespaces"
In-Reply-To: <37E23365.9E9F1104@infinet.com>
References: <199909171111.MAA14708@nag.co.uk>
Message-ID: <4.1.19990917094330.0251cd90@mail.webgeek.com>
At 08:26 AM 9/17/99 -0400, Tyler Baker wrote:
> Unfortunately, those who deal with WWW content almost
>exclusively in their jobs,
>will be forced to deal with the myriad of problems "Namespaces in XML"
>brings to XHTML. Even
>if XHTML were to have just one namespace, "Namespaces in XML" really mucks
>things up for what
>I always thought HTML was supposed to be in that it is a presentation format.
It's assertions like this that honestly confuse me. WWW content,rendered on
today's HTML browsers, cares not a whit about namespaces, so how does
having 3 complicate your life more than 1? We effectively have "0" since
the browsers don't use, acknowledge, or appreciate the namespace.
> Also, the fact that 99% of
>the posts on this
>list aside from Ann's are from men who need to get out more (including
>myself) makes it all
>the more encouraging to see someone like Ann challenge the incoming flood of
>testosterone that
>swamps this mailing list (-:
Would it help to know that in my "previous life" (of most of my 20s), I
spent nearly 10 years in the radio control room at the police department,
effectively telling 30-50 men where to go all night? ;)
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From david at megginson.com Fri Sep 17 15:46:19 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:07 2004
Subject: XML in the real world... Was "Re: Another look
atnamespaces"
In-Reply-To: <4.1.19990917092914.02187680@mail.webgeek.com>
References: <4.1.19990916120701.0249cb80@mail.webgeek.com>
<4.1.19990916181124.025d5510@mail.webgeek.com>
<4.1.19990917092914.02187680@mail.webgeek.com>
Message-ID: <14306.3604.241818.960359@localhost.localdomain>
Ann Navarro writes:
> For current HTML parsers, you need exactly *zero* namespaces. They aren't
> aware of them. They ignore them. (The same could be said for DTDs on the
> rendering side of things, though authoring is greatly aided by their
> inclusion).
That's not entirely true -- MSIE 5, which is very widely deployed,
*does* know about and use Namespaces for everything but HTML (because
there's not a standard HTML Namespace yet). I think that Mozilla
either does the same or is about to.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From ann at webgeek.com Fri Sep 17 15:47:13 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:08 2004
Subject: XML in the real world... Was "Re: Another look at
namespaces"
In-Reply-To: <14305.64593.302542.455403@localhost.localdomain>
References: <199909171111.MAA14708@nag.co.uk>
<199909171111.MAA14708@nag.co.uk>
Message-ID: <4.1.19990917094707.0218e8a0@mail.webgeek.com>
At 04:31 AM 9/17/99 -0400, David Megginson wrote:
>but I don't imagine that DMOZ or RPMFind will be
>able to become conformant any time soon because they have extremely
>large user bases with the old Namespace URI hard-coded in their
>software.
In all objectiveness, isn't that more a problem of it being "hard coded"
than of a change in URI?
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From david at megginson.com Fri Sep 17 15:52:08 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:08 2004
Subject: XML in the real world... Was "Re: Another look at
namespaces"
In-Reply-To: <4.1.19990917094707.0218e8a0@mail.webgeek.com>
References: <199909171111.MAA14708@nag.co.uk>
<4.1.19990917094707.0218e8a0@mail.webgeek.com>
Message-ID: <14306.3962.279889.493297@localhost.localdomain>
Ann Navarro writes:
> >but I don't imagine that DMOZ or RPMFind will be
> >able to become conformant any time soon because they have extremely
> >large user bases with the old Namespace URI hard-coded in their
> >software.
>
> In all objectiveness, isn't that more a problem of it being "hard
> coded" than of a change in URI?
That's the whole point of this discussion: Namespace URIs are
necessarily hard-coded in documents and applications. That's why many
of us want exactly one, persistent XHTML Namespace URI.
In this case, DMOZ and RPMFind did hard-code the Namespace URI before
RDF-Syntax went to REC, so technically, they're to blame; however, it
is unfortunately that the last-minute change robbed RDF of the chance
of having two very highly-visible and heavily-used conformant
implementations.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From paul at prescod.net Fri Sep 17 15:55:04 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun 7 17:15:08 2004
Subject: Abusing namespaces
References: <4.1.19990916122123.0248fbf0@mail.webgeek.com>
<199909161602.MAA09307@hesketh.net>
<5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> <4.1.19990916124455.024a9eb0@mail.webgeek.com>
Message-ID: <37E23A67.CFDD973C@prescod.net>
Ann Navarro wrote:
>
> I'm arguing that each flavor of XHTML is sufficiently different (idiom,
> dialect, what have you) that it deserves a different namespace.
Don't fall into this trap. Once we start quantifying differences based
on percentages of shared idioms we are into the land of voodoo
standardization.
We have three grammars. According to Chomsky and "formal languages 201"
this means we have three languages. I'll be happy to discard Chomsky
(what has he done for me LATELY) if someone comes up with something
better.
But I won't discard something I can implement in code in favor of "I
can't define a dialect but I know it when I see it." I can't code to
that and the scary thing is that Microsoft, Oracle and Netscape can't
either: so we are opening ourselves up to abuse.
"ORAHTML is a *dialect* of HTML so it uses the same namespace. It
crashes our competitor's products but that's not our problem."
If the defining characteristic of HTML is a single finite grammar then
we are safe. When we finish a well-defined extensibility model, we can
allow extensibility.
Paul Prescod
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)
From ann at webgeek.com Fri Sep 17 16:06:46 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:08 2004
Subject: XML in the real world... Was "Re: Another look
atnamespaces"
In-Reply-To: <14306.3604.241818.960359@localhost.localdomain>
References: <4.1.19990917092914.02187680@mail.webgeek.com>
<4.1.19990916120701.0249cb80@mail.webgeek.com>
<4.1.19990916181124.025d5510@mail.webgeek.com>
<4.1.19990917092914.02187680@mail.webgeek.com>
Message-ID: <4.1.19990917100638.025361e0@mail.webgeek.com>
At 05:47 AM 9/17/99 -0400, David Megginson wrote:
>Ann Navarro writes:
>
> > For current HTML parsers, you need exactly *zero* namespaces. They aren't
> > aware of them. They ignore them. (The same could be said for DTDs on the
> > rendering side of things, though authoring is greatly aided by their
> > inclusion).
>
>That's not entirely true -- MSIE 5, which is very widely deployed,
>*does* know about and use Namespaces for ******everything but HTML******
(because
>there's not a standard HTML Namespace yet). I think that Mozilla
>either does the same or is about to.
*****everything but HTML ******* (emphasis mine)
Which was my point.
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From ann at webgeek.com Fri Sep 17 16:12:02 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:08 2004
Subject: XML in the real world... Was "Re: Another look at
namespaces"
In-Reply-To: <14306.3962.279889.493297@localhost.localdomain>
References: <4.1.19990917094707.0218e8a0@mail.webgeek.com>
<199909171111.MAA14708@nag.co.uk>
<4.1.19990917094707.0218e8a0@mail.webgeek.com>
Message-ID: <4.1.19990917101151.02532f10@mail.webgeek.com>
At 05:52 AM 9/17/99 -0400, David Megginson wrote:
>That's the whole point of this discussion: Namespace URIs are
>necessarily hard-coded in documents and applications.
Documents, perhaps, but I haven't seen "necessarily" for applications. ?
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From murata.makoto at fujixerox.co.jp Fri Sep 17 16:18:05 1999
From: murata.makoto at fujixerox.co.jp (MURATA Makoto)
Date: Mon Jun 7 17:15:08 2004
Subject: First draft of proposed XML TC for Unicode 3.0 (unofficial)
Message-ID: <199909171422.AA02003@archlute.fujixerox.co.jp>
John Cowan writes:
>This is version 0.1 of a proposed technical corrigendum to XML 1.0
>to incorporate the new characters of Unicode 3.0 into the allowable
>sets used in XML Names. It presumes that XML should not
>remain limited to an obsolete version of the Unicode and ISO 10646
>standards.
I love the idea. This is certainly a great improvement.
I have one question. Is U+30FB (Katakana Middle Dot) a name character
in Unicode 3.0? I had a look at the WWW site of the Unicode Consortium,
but I could not find any information about it.
Omission of this character in Unicode (and thus XML) is very serious. This
character is so common. It is a very bad error of Unicode nameing rule.
In a meeting of Japanese Standardization Association, I was asked why this
character is not allowed as a name character in XML. Some users asked the
same question in an XML mailing list in Japan. This character is needed
very very badly.
I have spoken with some members of UTC and repeatedly asked them to make this
change. But I am still not sure if Unicode 3.0 allows this character as a
name character.
The second version of ISO TR 10176:1998 (Guideline for preparation of programming
language) also has a rule for name characters. This rule allows U+30FB as a
name character.
In the property list of Unicode, U+30FB is classified as hyphens.
Property dump for: 0x20000800 (Hyphen)
002D
00AD
058A
1806
2010..2011 (2 chars)
30FB
FE63
FF0D
FF65
If we cannot handle U+30FB as an exception, we can allow all these characters
except FE63, FF0D, FF65.
Makoto
Fuji Xerox Information Systems
Tel: +81-44-812-7230 Fax: +81-44-812-7231
E-mail: murata.makoto@fujixerox.co.jp
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)
From david at megginson.com Fri Sep 17 16:18:26 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:08 2004
Subject: XML in the real world... Was "Re: Another look at
namespaces"
In-Reply-To: <4.1.19990917094330.0251cd90@mail.webgeek.com>
References: <199909171111.MAA14708@nag.co.uk>
<4.1.19990917094330.0251cd90@mail.webgeek.com>
Message-ID: <14306.5515.101185.963225@localhost.localdomain>
Ann Navarro writes:
> It's assertions like this that honestly confuse me. WWW content,rendered on
> today's HTML browsers, cares not a whit about namespaces, so how does
> having 3 complicate your life more than 1?
I and others have pointed out several times that this assertion is not
true -- I know for certain that version 5 of Internet Explorer does
use Namespaces, and I think that Mozilla does as well.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From ann at webgeek.com Fri Sep 17 16:20:22 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:08 2004
Subject: Abusing namespaces
In-Reply-To: <37E23A67.CFDD973C@prescod.net>
References: <4.1.19990916122123.0248fbf0@mail.webgeek.com>
<199909161602.MAA09307@hesketh.net>
<5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08>
<4.1.19990916124455.024a9eb0@mail.webgeek.com>
Message-ID: <4.1.19990917101952.0253ee80@mail.webgeek.com>
At 02:56 PM 9/17/99 +0200, Paul Prescod wrote:
>Ann Navarro wrote:
>>
>> I'm arguing that each flavor of XHTML is sufficiently different (idiom,
>> dialect, what have you) that it deserves a different namespace.
>
>Don't fall into this trap. Once we start quantifying differences based
>on percentages of shared idioms we are into the land of voodoo
>standardization.
>
>We have three grammars. According to Chomsky and "formal languages 201"
>this means we have three languages. I'll be happy to discard Chomsky
>(what has he done for me LATELY) if someone comes up with something
>better.
Noted, and I agree. I suppose I was trying to use the language being tossed
around, and in doing so, have pointed out even to myself how weak those
labels are in the discussion at hand.
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From davidc at nag.co.uk Fri Sep 17 16:21:48 1999
From: davidc at nag.co.uk (David Carlisle)
Date: Mon Jun 7 17:15:08 2004
Subject: XML in the real world... Was "Re: Another look at
namespaces"
In-Reply-To: <4.1.19990917094330.0251cd90@mail.webgeek.com> (message from Ann
Navarro on Fri, 17 Sep 1999 09:46:19 -0400)
References: <199909171111.MAA14708@nag.co.uk> <4.1.19990917094330.0251cd90@mail.webgeek.com>
Message-ID: <199909171419.PAA19834@nag.co.uk>
Ann
> It's assertions like this that honestly confuse me. WWW content,rendered on
> today's HTML browsers, cares not a whit about namespaces, so how does
> having 3 complicate your life more than 1? We effectively have "0" since
> the browsers don't use, acknowledge, or appreciate the namespace.
Browsers today might not, but IE5 which is essentially namespace aware
would have cared except that I understand that it hard codes html:
(but given there wasn't (isn't) an official namespace for html this
is at least forgivable)
But if you have (as surely you will soon) a namespace aware browser
and want to say something like
top level HTML h1 elements should be rendered bold
but you don't want to affect other elements not related to html that
just happen to be called h1 then with the one namespace case (using xslt
syntax but that isn't really the point here) you just associate html:
with the html namespace (or make that namespace the default) and then go
(or ) ... in
either case this styling works for current and future flavours of HTML.
In the multiple namespace case it is really far more technical to write
a match that will find any element with local name h1 and namespace URI
beginning with a certain string.
It is not just for styling, if I want to index all top level section
elements I want to find all html h1 elements but not hit h1 elements
from some unrelated language.
the xpath expression "html:h1" (assuming xmlns:html has been suitably
declared somewhere) gets me exactly what I want in the one namespace
case. If you believe having separate namespaces for the three current
flavours and another one, xhtml1.1 on the way, is better, then please
write down the xpath expression to locate titles in HTML documents and
then try to convince us that it is better.
Something like
"*[starts-with(namespace(.),'http://www.w3.org/xxxx') and local-name(.)='h1']"
instead of
"html:h1"
Now perhaps you will just say it looks bad because the xpath syntax is
odd but I don't think that is the reason. The reason is that in order to
re-enforce the mechanisms (doctype) that an authoring tool has to guide
an HTML author into the a particular flavour of HTML you are suggesting
that you tell every XML namespace aware application that a frameset h1
is completely different from a transitional h1 which is completely
different from an xhtml 1.1 h1. This just will confuse everybody to the
point of breaking the entire system. No one will understand why they have
to use the above to access HTML h1 elements, when it is `clear' that
an html h1 is essentially the same thing in all flavours of html.
That's why they are all called h1, and why the flavours are all called
(x)html. That's why there should be one namespace.
David
PS
Using `flavour' because `dialect' appears too contentious:-) Use flavor
(I think?) if your dialect of English is different.
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)
From david at megginson.com Fri Sep 17 16:22:10 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:08 2004
Subject: XML in the real world... Was "Re: Another look
atnamespaces"
In-Reply-To: <4.1.19990917100638.025361e0@mail.webgeek.com>
References: <4.1.19990917092914.02187680@mail.webgeek.com>
<4.1.19990916120701.0249cb80@mail.webgeek.com>
<4.1.19990916181124.025d5510@mail.webgeek.com>
<4.1.19990917100638.025361e0@mail.webgeek.com>
Message-ID: <14306.5760.20065.372291@localhost.localdomain>
Ann Navarro writes:
> >That's not entirely true -- MSIE 5, which is very widely deployed,
> >*does* know about and use Namespaces for ******everything but HTML******
> (because
> >there's not a standard HTML Namespace yet). I think that Mozilla
> >either does the same or is about to.
>
> *****everything but HTML ******* (emphasis mine)
>
> Which was my point.
They still use Namespaces in HTML documents, though -- it's just HTML
itself that lacks a Namespace. It's a crime, really, that they ended
up having to hard-code the 'html' prefix for lack of a standard
Namespace. We (and I include myself) really missed the boat on that
one: it's a rare opportunity where the W3C could actually have made a
difference in deployed software, and MS would have been happy for the
guidance. Now we already face the possibility of nasty inter-op
problems.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From donpark at docuverse.com Fri Sep 17 16:31:30 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun 7 17:15:08 2004
Subject: Binary-encoding of XML for communication
In-Reply-To: <01de01bf010a$be84d3e0$a60a1712@col.w3.org>
Message-ID: <000201bf0119$c27dd5a0$74bbfea9@w21tp>
>I know it is nice to stick with text (and compression if
>necessary) but if binary XML is going to happen anyway,
>would it not be wise for the XML community to be involved
>so as to ensure that it was absolutely equivalent to XML+NS?
I believe binary XML is inevitable. XML, as a concept, is not specific to
text and certain applications will require binary XML for performance,
environment constraints, etc. One caveat is that it is difficult to come up
with one binary format that fits all situations.
XML is already being compressed via modems as Andrew mentioned, but as
broadband use increases the compression factor will be lost. Some might
argue that compression is not necessary when broadband is the norm but I
think not. Waste is waste and bandwidth is like memory in that one can
never have enough.
I am with TimBL on the issue with binary XML. WAP is all right but not good
enough for general use. We need to put our heads together and squeeze one
out. I think it should support exactly one namespace (just kidding :).
Best,
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
From david-b at pacbell.net Fri Sep 17 16:34:26 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun 7 17:15:08 2004
Subject: Abusing namespaces
References: <4.1.19990916122123.0248fbf0@mail.webgeek.com>
<199909161602.MAA09307@hesketh.net>
<5BF896CAFE8DD111812400805F1991F712E172BB@RED-MSG-08> <4.1.19990916124455.024a9eb0@mail.webgeek.com> <37E23A67.CFDD973C@prescod.net>
Message-ID: <37E251C9.DF27E7EA@pacbell.net>
Paul Prescod wrote:
>
> We have three grammars. According to Chomsky and "formal languages 201"
> this means we have three languages.
Curiously, that's _not_ what the HTML spec says. I'm amused that
nobody from W3C has responded to my points that the HTML spec uses
language like "ONE LANGUAGE" and "THE LANGUAGE" (emphasis added)
concurrently with its "three DTDs" wording ... so the W3C is
inconsistent in its use of terminology, since the terms actually
used in the HTML spec do not support the stance defending XHTML.
My radar always starts malfunctioning when I'm trying to have a
rational discussion with folk who redefine terminology to support
their points, as soon as it gets inconvenient.
The HTML world is sufficiently imprecise that the formal languges
perspective isn't applicable in any straightforward manner. Else
surely over 90% of the HTML in the world would not be viewable in
a browser -- it'd get rejected as rife with syntax errors.
- Dave
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)
From ann at webgeek.com Fri Sep 17 16:37:18 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:09 2004
Subject: XML in the real world... Was "Re: Another look at
namespaces"
In-Reply-To: <14306.5515.101185.963225@localhost.localdomain>
References: <4.1.19990917094330.0251cd90@mail.webgeek.com>
<199909171111.MAA14708@nag.co.uk>
<4.1.19990917094330.0251cd90@mail.webgeek.com>
Message-ID: <4.1.19990917103725.0253aaf0@mail.webgeek.com>
At 06:18 AM 9/17/99 -0400, David Megginson wrote:
>Ann Navarro writes:
>
> > It's assertions like this that honestly confuse me. WWW content,rendered on
> > today's HTML browsers, cares not a whit about namespaces, so how does
> > having 3 complicate your life more than 1?
>
>I and others have pointed out several times that this assertion is not
>true -- I know for certain that version 5 of Internet Explorer does
>use Namespaces, and I think that Mozilla does as well.
For HTML.
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From david-b at pacbell.net Fri Sep 17 16:38:28 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun 7 17:15:09 2004
Subject: Another look at namespaces
References: <006101beffba$a2984280$a60a1712@col.w3.org> <4.1.19990916092628.02454100@mail.webgeek.com>
Message-ID: <37E2529D.B4A6AE83@pacbell.net>
Ann Navarro wrote:
>
> At 02:12 AM 9/16/99 -0700, David Brownell wrote:
>
> >> The exciting use of namespaces in schemas will be when ...
> >
> >That's all quite true! But it doesn't require any inflexible
> >one-to-one association of namespace URIs and schemas (or DTDs).
>
> I've yet to see anyone assert that it must.
That was the gist of Tim's point that the "definitive"
schema would be found at the end of the namespace URI.
Something can't be both optional and definitive in that
way ... if it's optional, some other way could be be
at least as correct/definitive.
- Dave
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)
From david at megginson.com Fri Sep 17 16:41:17 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:09 2004
Subject: XML in the real world... Was "Re: Another look at
namespaces"
In-Reply-To: <4.1.19990917103725.0253aaf0@mail.webgeek.com>
References: <4.1.19990917094330.0251cd90@mail.webgeek.com>
<199909171111.MAA14708@nag.co.uk>
<4.1.19990917103725.0253aaf0@mail.webgeek.com>
Message-ID: <14306.6895.781035.218125@localhost.localdomain>
Ann Navarro writes:
> At 06:18 AM 9/17/99 -0400, David Megginson wrote:
> >Ann Navarro writes:
> >
> > > It's assertions like this that honestly confuse me. WWW content,rendered on
> > > today's HTML browsers, cares not a whit about namespaces, so how does
> > > having 3 complicate your life more than 1?
> >
> >I and others have pointed out several times that this assertion is not
> >true -- I know for certain that version 5 of Internet Explorer does
> >use Namespaces, and I think that Mozilla does as well.
>
> For HTML.
That's tautological -- since there isn't a standard Namespace for
HTML, browsers can hardly use a standard HTML Namespace. The proof of
the success (and necessity) of Namespaces is that browsers are using
Namespaces for lots of other stuff now, and they they are using
Namespaces to disambiguate everything else *from* HTML in an HTML
document.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From ann at webgeek.com Fri Sep 17 16:44:17 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:09 2004
Subject: Another look at namespaces
In-Reply-To: <37E2529D.B4A6AE83@pacbell.net>
References: <006101beffba$a2984280$a60a1712@col.w3.org>
<4.1.19990916092628.02454100@mail.webgeek.com>
Message-ID: <4.1.19990917104404.0254a100@mail.webgeek.com>
At 07:39 AM 9/17/99 -0700, David Brownell wrote:
>Something can't be both optional and definitive in that
>way ... if it's optional, some other way could be be
>at least as correct/definitive.
Yes, it very well could. I don't see them as being mutually exclusive.
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From donpark at docuverse.com Fri Sep 17 16:45:53 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun 7 17:15:09 2004
Subject: A compromise?
Message-ID: <000401bf011b$dc47c8e0$74bbfea9@w21tp>
What if we came up with a way to associate a schema with any element without
using namespace? Would it address the real concerns of the HTML WG?
Something like:
Hello, world!
blah blah
Except it doesn't use the !DOCTYPE.
How about it?
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
From ann at webgeek.com Fri Sep 17 17:04:49 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:09 2004
Subject: XML in the real world... Was "Re: Another look at
namespaces"
In-Reply-To: <14306.6895.781035.218125@localhost.localdomain>
References: <4.1.19990917103725.0253aaf0@mail.webgeek.com>
<4.1.19990917094330.0251cd90@mail.webgeek.com>
<199909171111.MAA14708@nag.co.uk>
<4.1.19990917103725.0253aaf0@mail.webgeek.com>
Message-ID: <4.1.19990917110449.02391f00@mail.webgeek.com>
At 06:41 AM 9/17/99 -0400, David Megginson wrote:
>Namespaces for lots of other stuff now, and they they are using
>Namespaces to disambiguate everything else *from* HTML in an HTML
>document.
Except that you can't have a valid HTML document that has "everything else"
in it.
MS may have cobbled the 'html' namespace to allow their xml-islands
approach, but it's operating outside the spec as you've pointed out.
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From david-b at pacbell.net Fri Sep 17 17:06:46 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun 7 17:15:09 2004
Subject: Another look at namespaces
References: <006801bf0068$fcdb9130$1ff96d8c@NT.JELLIFFE.COM.AU> <37E2357C.FDAD0C55@prescod.net>
Message-ID: <37E2593B.2C01A3C@pacbell.net>
Paul Prescod wrote:
>
> Rick Jelliffe wrote:
> >
> > It seems clear that the HTML team have some mental concept of namespaces
> > which exists independently of what the W3C specification actually
> > allows.
>
> I think that you are putting the blame in the wrong place. A quick
> perusal of this forum suggests that the namespace editors disagree on
> what the namespace specification "really means". It seems to me that the
> specification has proven too general, too flexible and has been shown to
> depend too much on mystical shared understanding of a "reasonable
> namespace" that turns out not to be shared.
The namespaces spec did sort of get rushed through at the last minute,
with a PR that said "this is how it'll be, don't bother sending any
comments unless you can prove the sky is falling". As of course it
could not be.
Perhaps a lot of the current problems with XHTML map to such issues.
Rush one spec through with some open issues, and then watch the issues
multiply as time goes by.
- Dave
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)
From grove at infotek.no Fri Sep 17 17:08:35 1999
From: grove at infotek.no (Geir Ove Grønmo)
Date: Mon Jun 7 17:15:09 2004
Subject: Another try on groves
In-Reply-To:
References: <37E1532B.82F3BB03@prescod.net> <37E20A5C.75E79B93@redrice.com>
Message-ID:
* Ken MacLeod
| Francis Norton writes:
|
| > Now that I have some feeling for the rationale behind Groves, I'd be
| > very interested in knowing what this might mean for implementations.
| >
| > Could one come up with a language independent API like the DOM, to
| > which Grove compliant APIs would conform? Presumably there is more
| > complexity in that the DOM has a closed set of underlying object
| > types whereas each Grove interface would would have different
| > underlying object types. In Java terms, would this be an interface
| > (a totally abstract class which guarantees a core functionality in
| > any object which implements it)? Has anyone in fact built CORBA IDL
| > or a Java interface defining the Grove API, or am I coming in at the
| > wrong level?
|
| I'd like to believe you're coming in at the wrong level. Many
| languages have built-in syntax to access ``members of objects'' or
| ``fields of records'' that can often be applied to accessing
| ``properties of nodes''. In this case, the grove API is the
| language's native syntax.
|
| Where native syntax is not applicable, groves most closely resemble
| container classes (dictionaries, mappings, hash tables; lists, arrays,
| sequences). Again, a language's standard container class interface or
| protocol can be used.
Yes. Think of it more as a data structure instead of as an API, since
there are no methods involved.
Geir O.
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)
From ken at bitsko.slc.ut.us Fri Sep 17 17:37:28 1999
From: ken at bitsko.slc.ut.us (Ken MacLeod)
Date: Mon Jun 7 17:15:09 2004
Subject: groves.org already taken
Message-ID:
I've found a domain, web, and mail hosting site that could host a
grove home, but the obvious ``grove.org'' and ``groves.org'' are
already taken. Suggestions for other possible names are welcome.
Ideas we've already come up with are:
opengroves.org
grovemodel.org
www.xml.com/groves
--
Ken MacLeod
ken@bitsko.slc.ut.us
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)
From david-b at pacbell.net Fri Sep 17 17:45:55 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun 7 17:15:09 2004
Subject: Another look at namespaces
References: <006101beffba$a2984280$a60a1712@col.w3.org>
<4.1.19990916092628.02454100@mail.webgeek.com> <4.1.19990917104404.0254a100@mail.webgeek.com>
Message-ID: <37E26274.903E443F@pacbell.net>
Ann Navarro wrote:
>
> At 07:39 AM 9/17/99 -0700, David Brownell wrote:
>
> >Something can't be both optional and definitive in that
> >way ... if it's optional, some other way could be be
> >at least as correct/definitive.
>
> Yes, it very well could. I don't see them as being mutually exclusive.
If an alternative can be more correct, then how could that
one approach (overloading the namespace URI to point to one
type of schema information) possibly be definitive ???
Perhaps you could elaborate on your logic here, concretely
in the case of XHTML.
There are a lot of issues that seem to get conflated in
this XHTML-oriented namespace discussion:
- "what's a language" ... side issue except that
the HTML spec ("one language") is claimed to
describe three ("three DTDs") and this ties to
the next issue
- "how do namespaces and DTDs relate" ... HTML WG
has chosen a 1-1 mapping, which stance isn't
in the least bit conservative (causing trouble)
- "how do namespaces and schemas relate" ... not
yet answerable, and also not the same as the DTD
issue, since what different sorts of schemas will
do/say/mean is still under discussion
- "what do namespaces signify" ... the namespace
spec says namespaces are used to disambiguate
_names_ but some attribute more to it than that
(notably wanting schema coupling approaches)
The problem with the WG's non-conservative stance is clearly
that it's in conflict with a lot of things that the developer
community is doing, which IS conservatively following that
namespace spec: using namespace URIs to indicate _only_ the
vocabulary selection, and using other mechanisms to establish
couplings for various types of semantics. (Where "validity"
checking is one kind of optional semantic constraint.)
Perhaps rather than arguing about who's right and who's wrong,
or trying to argue vision statements, the discussion could more
usefully be about how the HTML WG can more usefully work with
the XML developer community it's targetting with XHTML. That
relationship is clearly not collaborative today; it should be.
- Dave
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)
From James.Anderson at mecomnet.de Fri Sep 17 18:08:08 1999
From: James.Anderson at mecomnet.de (james anderson)
Date: Mon Jun 7 17:15:09 2004
Subject: Another look at namespaces
References: <01ec01bf010f$2b389950$a60a1712@col.w3.org>
Message-ID: <37E2680C.64449633@mecomnet.de>
Tim Berners-Lee wrote:
>
>
> We either have a different use of words or a very serious
> problem.
I suspect the potential for a serious problem.
> Whereas with natural langauge, meanings change and
> grow and everyone has slightly different associations with a word,
> in computer languages we need to build on top of XML we need
> to have the ability to define meaning precicely in terms of
> other existing languages.
>
> If you believe that "HTML 4.0" specification - and a schema for XHTML -
> can decied that cannot occur in
then do you not grant
> th ewriters of the spec the right to make that definitiove assertion (in
> prose
> or schema) whatever code someone may or may not write to produce or
> parse inside
Yes, but with respect to the DTD, not the namespace.
There are no grounds to take issue with the XHTML specification where it
prescribes a specific interpretation to the element
<{http://www.w3.org/TR/xhtml1/strict}p> in the presence of the respective
document type declaration
but any claims that the interpretation should arise directly from the
evocation of the namespace "{http://www.w3.org/TR/xhtml1/strict}p" are
misleading. That is, the permission granted in 3.1.1#4, that the external
identifier need not be present, ascribes to the respective root xmlns
attribute a meaning which is neither asserted in the namespace recommendation,
nor adequately specified in the XHTML pr itself.
In this regard, i have two questions:
1) what is the status of a document which "evokes" the namespace
"http://www.w3.org/TR/xhtml1/DTD/strict.dtd"
but contains no document type declaration? Is it XHTML conformant but of
indeterminate XML validity?
2) what is the status of a document which "evokes" this namespace, but
contains a document type declaration with respective element declarations
which differ from those in the above mentioned dtd? I suspect that it is XHTML
non-conformant but of determinate XML validity
ie. the evocation of the namespace is, in itself, immaterial.
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)
From david-b at pacbell.net Fri Sep 17 18:09:32 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun 7 17:15:09 2004
Subject: A compromise?
References: <000401bf011b$dc47c8e0$74bbfea9@w21tp>
Message-ID: <37E2682E.7CEAB54B@pacbell.net>
Don Park wrote:
>
> What if we came up with a way to associate a schema with any element without
> using namespace? Would it address the real concerns of the HTML WG?
I'm also curious why the HTML WG should care, since (X)HTML has
only DTDs (currently three of them) for which there's already
a standard association technique:
Seems to me that the best compromise is to stick exclusively to what
is already accepted -- ruling out schemas.
- Dave
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)
From david-b at pacbell.net Fri Sep 17 18:21:42 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun 7 17:15:09 2004
Subject: Associating Element Node to Document Node
References: <8B049D471C61D111847C00805FA67B1C03239D00@usa0129ms1.ess.mc.xerox.com>
Message-ID: <37E26B07.7A398B7@pacbell.net>
For the record, I replied privately that package-internal
property APIs like setOwnerDocument() shouldn't be used here.
There's a public XmlDocument.changeNodeOwner() method that does
the job nicely, including all the additional checks needed
in a public API. Since it's a computed property, "nodeOwner"
wasn't intended to look like a simple JavaBeans property.
- Dave
"Goyal, Sanjeev" wrote:
>
> I am using Sun's XML Parser and DOM implementation (Java Project X Core
> Library TR2)
>
> -----Original Message-----
> From: Goyal, Sanjeev
> Sent: Monday, September 13, 1999 6:20 PM
> To: 'xml-dev@ic.ac.uk'; 'xml-feedback@java.sun.com'
> Subject: Associating Element Node to Document Node
>
> Hi,
>
> I want to associate a ElementNode to a Document before I append the
> Element to DocumentNode. Basically, I am specializing the ElementNode and
> writing my own element nodes. I have a specific requirements to do that.
> Following is the code snippet:
>
> public class TestNode extends ElementNode
> {
> public TestNode(XmlDocument parentDoc)
> {
> super();
> setTag("SIFNode");
> setOwnerDocument(parentDoc);
> }
>
> }
>
> I am not able to use the setOwnerDocument() API. Please help me in
> this regard.
>
> Thanks,
> Sanjeev
>
> 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)
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)
From mnutter at fore.com Fri Sep 17 18:58:07 1999
From: mnutter at fore.com (Mark Nutter)
Date: Mon Jun 7 17:15:09 2004
Subject: groves.org already taken
In-Reply-To:
Message-ID: <4.2.0.58.19990917123418.00c9ca00@pophost1.fore.com>
At 10:37 AM 09/17/99 -0500, Ken MacLeod wrote:
>I've found a domain, web, and mail hosting site that could host a
>grove home, but the obvious ``grove.org'' and ``groves.org'' are
>already taken. Suggestions for other possible names are welcome.
>Ideas we've already come up with are:
>
> opengroves.org
> grovemodel.org
> www.xml.com/groves
"groves-r-us.org"? :-)
Seriously, I like grovemodel.org the best. Actually, I like xml.org/groves
best, but I have the impression it rather implies that groves are strictly
an xml thing -- IOW it risks giving a false impression. On the other hand,
that might be a trivial objection rather than a real, practical difficulty.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Mark Nutter,
Internet Applications Developer
FORE Systems
Some people are atheists 'til the day they die.
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)
From malliks at rocketmail.com Fri Sep 17 18:58:13 1999
From: malliks at rocketmail.com (Mallikarjuna Sangappa)
Date: Mon Jun 7 17:15:09 2004
Subject: XML Schemas in XT
Message-ID: <19990917170005.8277.rocketmail@web4.rocketmail.com>
Hi,
Is it possible to translate XML Documents created out
of XML Schemas instead of XML DTDs? TIA.
Mallik
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
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)
From tbray at textuality.com Fri Sep 17 19:50:23 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun 7 17:15:09 2004
Subject: On a more pleasant note
Message-ID: <3.0.32.19990917105301.012183e0@pop.intergate.bc.ca>
There's been a lot of angst around here recently. On a countervailing note:
I am building this big hairy complicated app in which a web server traverses
an extremely complex database, extracts some dense information structures,
sends them to a client, and the client does some nifty rendition tricks.
Building the database is hard. Traversing the database is hard. Doing the
rendition on the client is hard. But generating the message on the server
takes one little C subroutine (printf calls, nothing fancy), and extracting
the information from it on the client (using an XML parser, it doesn't
matter which) is one little Java routine. The client-side worked first
time, the server-side on the second (I wasn't escaping some &'s properly,
which the XML parser on the client caught first time through). All the
rest is done by Apache and Linux and Windows and TCP/IP and HTTP and
java.net.URL and the XML parser. It took maybe an hour to build both sides.
Seems to me that this is the right way to build distributed applications.
-Tim
PS: In the XML I'm sending out from the server, I am embedding some human
readable text encoded, obviously enough, in HTML. What would be a good way
to distinguish it from my own XML tags so that I can extract it and feed
it to the HTML renderer? Any suggestions?
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)
From Daniel.Veillard at w3.org Fri Sep 17 20:24:51 1999
From: Daniel.Veillard at w3.org (Daniel Veillard)
Date: Mon Jun 7 17:15:10 2004
Subject: On a more pleasant note
In-Reply-To: <3.0.32.19990917105301.012183e0@pop.intergate.bc.ca>
References: <3.0.32.19990917105301.012183e0@pop.intergate.bc.ca>
Message-ID: <19990917142707.D3880@w3.org>
> Building the database is hard. Traversing the database is hard. Doing the
> rendition on the client is hard. But generating the message on the server
> takes one little C subroutine (printf calls, nothing fancy), and extracting
> the information from it on the client (using an XML parser, it doesn't
> matter which) is one little Java routine. The client-side worked first
> time, the server-side on the second (I wasn't escaping some &'s properly,
> which the XML parser on the client caught first time through). All the
> rest is done by Apache and Linux and Windows and TCP/IP and HTTP and
> java.net.URL and the XML parser. It took maybe an hour to build both sides.
Good :-)
> Seems to me that this is the right way to build distributed applications.
If this community succeeded where 20 years of research in distributed
computing failed to provide, we should try to see things in an optimistic
way.
> PS: In the XML I'm sending out from the server, I am embedding some human
> readable text encoded, obviously enough, in HTML. What would be a good way
> to distinguish it from my own XML tags so that I can extract it and feed
> it to the HTML renderer? Any suggestions?
I bet the game is to answer "an HTML namespace" and you beat me
with a stick for a few hours while asking "which one", right ;-)
Daniel, obviously speaking for himself
--
Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes | Today's Bookmarks :
Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux, WWW, rpmfind,
Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | rpm2html, XML,
http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe.
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)
From schen at falconwing.com Fri Sep 17 20:20:58 1999
From: schen at falconwing.com (schen@falconwing.com)
Date: Mon Jun 7 17:15:10 2004
Subject: groves.org already taken
In-Reply-To: <4.2.0.58.19990917123418.00c9ca00@pophost1.fore.com>
Message-ID:
On Fri, 17 Sep 1999, Mark Nutter wrote:
> At 10:37 AM 09/17/99 -0500, Ken MacLeod wrote:
> >I've found a domain, web, and mail hosting site that could host a
> >grove home, but the obvious ``grove.org'' and ``groves.org'' are
> >already taken. Suggestions for other possible names are welcome.
> >Ideas we've already come up with are:
> >
> > opengroves.org
> > grovemodel.org
> > www.xml.com/groves
>
> Seriously, I like grovemodel.org the best.
[ ... ]
I second the motion =)
So is there a call to arms here? I'd gladly collaborate with anyone else
interested in defining the XML InfoSet in grove terms, and also a Java API
for groves.
. . . Sean.
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)
From timbl at w3.org Fri Sep 17 20:39:01 1999
From: timbl at w3.org (Tim Berners-Lee)
Date: Mon Jun 7 17:15:10 2004
Subject: Another look at namespaces
Message-ID: <01ff01bf013c$2923a290$a60a1712@col.w3.org>
-----Original Message-----
From: Rick Jelliffe
>The only information that properly belongs in a namespace is a list of
>names.
That is not useful. I realize that the word "Namespace" (as the end result
fo the discussions of modules or docuemnt types or vocabularies or...)
may be an english word which does not convey this, but a
a namespaces is a language: a set of names plus a set of syntactic
constraints plus - to be useful - a meaning shared by writer and recipient.
That meaning can be to a certian (and, with technology, growing)
extend by expressed formally in a mapping to other languages.
Or is can be disccussed in the bar, a mid: URI written on the
back of napkin, and used from then on by the people who were
in the bar in the messages they write to each other.
>All other information, however convenient, is not namespace information
>but something else: what is this "intent" business? There is no mention
>of
>"intent" in the namespaces spec that I recall, quite the opposite. The
>fundamental justification for namespace is to be free from intent.
The generic Namepsaces draft only indicates how to identify names in a
document
by a URI of a namespace. It doesn't say anything about the meaning of any
namespace because it is not that spec which allows one to talk about it.
However, the namespace URI is the hookto which the whole of the rest of the
system can be attached: it allows one in a schema or other document to say
what the names "mean" for any particular level of "meaning".
>There is no W3C method to define a namespace as list of names.
There is an xml-schema spec in the works destined to do that
and more.
One can either take the existing specs at face value at any point in
history,
and not complain about the lack of functionality. Or you can work with
the model which you forsee you can
>There is no
>W3C method to declare which schema should be used, akin to the
>stylesheet declaration.
Yes there is: resolution of the schema URI.
>In the absense of these, of course people will
>try to
>turn namespaces URIs into schema declaration URLS.
"URL" is a term some use to refer to a subset of URIs
which have a network protocol for being dereferenced.
If you access a schema fro the URI you are dereferencingthe URI
whatever the number indirections you migh go through.
> The W3C should
>provide a proper way to define namespaces (as simple lists) and a
>way to declare schemas.
Forgive me if I am missing something but do you mean
XML Schema Part 1: Structures
http://www.w3.org/1999/05/06-xmlschema-1/
> (Furthermore, the idea of a namespace-author
>being in some way the controller of the resource for a schema is bad;
Why?
(To eleborate a little, the publisher of a reseource is the controller
of the mapping between the URI and the result of dereferencing that URI.
I should have said "namespace-publisher". Authors and publishers tend
to have a close understanding like a contract. But I don't think that detail
is what you are getting at)
>a schema identifier (or a namespace list) should be identified using
>the URI equivalent of a Formal Public Identifier: I can ask some service
>to provide me that schema (or that namespace list) in any format
>that anyone has chosen to make available.)
Of course. You could use an md5: for example or a uuid or a
mid: You can do that with an HTTP URI too. You can ask anyone
for a copy of http://www.w3.org/1999/05/06-xmlschema-1/
... the HTTP 1.1 spec only gives you a cannonical way of
getting a definitive copy.
So longas you own the DNS name, you can use any part of
HTTP space as a FPI-like space. (eg see http://purl.org/)
>>While there are many processes that can be applied to a document, and
>>correspondingly many specifications of those processes, there can be,
>for a
>>given term in a namespace, at most one correct *definition*.
>
>Again, the only declaration information that is proper to a namespace
>is a list of names. A content model is a schema, and nothing to do with
>names in a namespace, in particular.
I don't understand how you say that the content model has nothing to do
with the list of names. It lists the names and says how they can be
combined.
[...]
>Again, Andrew is simply conflating schema and namespace. The idea that
>he and Tim are putting forward is that a language is defined by a single
>set of content models; this confuses "language" with "grammar" and
>is disproved by long-standing SGML practise,
(disproved by practise?)
> in which variants of
>a language can be defined in the same DTD (selected by marked sections,
>or by simply overriding parameter entity declarations).
You can refer to SGML as a language in its entirety,
(containing all possible bits of SGML as combined according to the
spec) and you refer to a document type in SGML as a
language, consisting of all possible documents fo a given type.
You could define the set of all parameterisable document types
as a language, or one parameterised type inwhich you
exclude any further declarations or parameterization as a language.
But if you want to keep the word "language" which has no formal
definition at all, then I will have to find another.
>I think the problem is the bad idea that content models *define* a
>language rather
>than simply *describe* or *declare* it.
I can go along with that. A content model defines the set of names, and
constrains the
ways in which they can syntactically be combined. Other languages
(such as rdf-schema and futher languages a la Semantic Web Toolbox
http://www.w3.org/DesignIssues/Toolbox musings) could more be said
to "define" the names in a namespace.
[...]
>>Further, I expect that one can argue that a namespace is an abstract
>concept
>>denoting a set of names, and this argument is true, so far as it goes,
>but
>>it does not go far enough: For specific processing, to make use of a
>>namespace one needs to know what names are in it, which are not, and
>what
>>the meaning is for each name
Absolutely. One needs to knwo the meaning of the each name
in order to know the meaning of the document.
>Here is the crux: Andrew is saying a namespace mechanism should provide
>more
>than just a space of names! He says it should also provide meanings. If
>it does so,
>it is not a namespace, but a schema.
Hang on. The namespace is an asbtract thing, (like software module).
A schema is a document which tells you some information about it
the namespace.
It may contain information in various langauges. In particular,
the xml schema draft gives you a way of expressing an XML content model.
Other languages will allow one (in the same document) to provide
"meaning" by mapping onto some other vocabulary.
>Andrew is saying that we should
>not have namespaces but schemas. This is a legitimate view, but it utterly
>flies in the face of the current spec and all previous pronouncements on
>it.
I didn't hear Andrew saying that. He seems to say "The specification does
not require that a namespace correspond to anything like a schema; but
neither does it forbid such correspondence, either
generally or in specific contexts."
>If W3C says a namespace is a schema, they should withdraw the XML
>Namespaces Spec immediately. As I emailed a month ago, Namespaces is dead.
Not by
>neglect but by abuse.
You seem agitated about this, but as I don't understand your complaint yet.
I have noone associated with W3C say that a "a namespace is a schema"
so I suppose I don't have to understand the rest of your paragraph, which ?s
good because I don't. I hope thay I can see though your clear agitation
about this to the misunderstand someone must have somewhere.
>Rick Jelliffe>
Tim BL
in no offical capacity
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)
From timbl at w3.org Fri Sep 17 21:16:59 1999
From: timbl at w3.org (Tim Berners-Lee)
Date: Mon Jun 7 17:15:10 2004
Subject: Another look at namespaces
Message-ID: <028801bf0141$9f63c0c0$a60a1712@col.w3.org>
Philip Nye wrote on Thursday, September 16, 1999
5:54 AM
>Tim Berners-Lee wrote:
[...]
>> I feel that language subsets are completely well defined, by the change
>> of namsespace preserving validity.
>I get the strong sense that your view is that subsetting is "good" and
>useful (my own feelings exactly).
We agree.
> What I don't understand is why this
>obvious point is not reflected in the namespace spec.
The namespace spec had its work cut out finding a syntax for
declaring and use name prefixes.
Lots of folks wanted namespaces ASAP and so making remarks
that "subsets relationships are very helpful" or even better
defining an RDF property so that processors everywhere
can use it probably would have delayed the spec.
I don't in fact think that the namsepaces spec would have been
the best place for it.
But it sounds as though the xml-schema group *would* do well
to define this relationship. After all, it is just the sort of useful
thing as you point out one would naturally expect to find in the
schema, and the xml-schema langauge seems appropriate.
>Namespaces have no structure whatever. Schemata have lots of structure
>but no guaranteed recognition and access mechanism.
An access mechnaism for a URI to a document is well defined for
many URI schemes. If you need it, use one,like HTTP, which has
an access mechanism.
>Philip Nye
>Engineering Arts UK
Tim
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)
From david at megginson.com Fri Sep 17 21:20:40 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:10 2004
Subject: Another look at namespaces
In-Reply-To: <01ff01bf013c$2923a290$a60a1712@col.w3.org>
References: <01ff01bf013c$2923a290$a60a1712@col.w3.org>
Message-ID: <14306.23748.964502.765514@localhost.localdomain>
Tim Berners-Lee writes:
> That is not useful. I realize that the word "Namespace" (as the
> end result fo the discussions of modules or docuemnt types or
> vocabularies or...) may be an english word which does not convey
> this, but a a namespaces is a language: a set of names plus a set
> of syntactic constraints plus - to be useful - a meaning shared by
> writer and recipient.
As (I think) Tim is arguing later in his message, a Namespace is a
component of a vocabulary: specifically, it's the mechanism that XML
documents use to represent (and disambiguate) the names that are part
of a vocabulary, but, as Rick argues, it's not the vocabulary itself.
Since Paul Prescod mentioned Chomsky, I'll mention Saussure: like
written or spoken words, a namespace-qualified name is a pure signifiant without any signifi?e .
For example, the signifier "{http://www.megginson.com/ns/}apt" can be
represented by Namespaces. The signified (say, "a valid ICAO airport
code") cannot be represented by Namespaces, but for now will probably
be represented in human-readable documentation and hard-coded in
applications.
I guess that a machine-readable schema could constrain the element to
contain up to four alphanumeric characters, but who cares, really? My
application still has to know somehow that it's an airport code and it
has to know what it wants to do with airport codes (sell you a ticket?
give you driving directions? tell you that the document contains a
match for the code you were looking for?).
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From bpaul at wbtsystems.com Fri Sep 17 21:41:12 1999
From: bpaul at wbtsystems.com (Barry Paul)
Date: Mon Jun 7 17:15:10 2004
Subject: On a more pleasant note
In-Reply-To: <3.0.32.19990917105301.012183e0@pop.intergate.bc.ca>
Message-ID: <001b01bf0145$54f225f0$8e5ca3ce@mumble.wbtsystems.com>
> PS: In the XML I'm sending out from the server, I am embedding some human
> readable text encoded, obviously enough, in HTML. What would be
> a good way
> to distinguish it from my own XML tags so that I can extract it and feed
> it to the HTML renderer? Any suggestions?
Yep, three:
1. Use namespaces (seriously!)
2. Encode '<', '>', etc using entities
3. Enclose the HTML CDATA sections
Problems with each solution:
1. This is OK if you are sure that the HTML is valid and well formed
2. What else would you have to encode? (HTML entities?)
3. Maybe some whitespace issues
Seems like number 3 would be a good way to go.
Cheers,
-----
Barry
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)
From david at megginson.com Fri Sep 17 22:02:54 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:10 2004
Subject: On a more pleasant note
In-Reply-To: <001b01bf0145$54f225f0$8e5ca3ce@mumble.wbtsystems.com>
References: <3.0.32.19990917105301.012183e0@pop.intergate.bc.ca>
<001b01bf0145$54f225f0$8e5ca3ce@mumble.wbtsystems.com>
Message-ID: <14306.26269.359383.260896@localhost.localdomain>
Barry Paul writes:
> 1. Use namespaces (seriously!)
> 2. Encode '<', '>', etc using entities
> 3. Enclose the HTML CDATA sections
[snip]
> 1. This is OK if you are sure that the HTML is valid and well formed
> 2. What else would you have to encode? (HTML entities?)
> 3. Maybe some whitespace issues
>
> Seems like number 3 would be a good way to go.
Actually, it's by far the worst of the three. When someone is
actually generating the markup (as Tim is in this case), then there
are immense advantages to being able to process the HTML with the same
software as the rest of the document, so #1 is far and away the
winner. After all, the human-readable documentation is meant to be
part of the document.
#2 is also pretty awful, but at least it won't blow up if the HTML
happens to contain the "]]>" character sequence (say, as an
emoticon?).
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From jesmith at kaon.com Fri Sep 17 22:04:41 1999
From: jesmith at kaon.com (Joshua E. Smith)
Date: Mon Jun 7 17:15:10 2004
Subject: Nimble: An XML conformant programming language
Message-ID: <3.0.1.32.19990917155708.008b9bb0@tiac.net>
Gurus and others,
You may recall that several months ago, I used this list as a resource in
figuring out how to make a programming language which conforms to XML 1.0.
Despite the fact that you all thought I was nuts, it's now done, and I
think it's pretty cool.
The language, called "Nimble" drives a Windows web browser plugin (now
porting to other platforms). The language encapsulates an object model for
3D scene description, distributed simulation, user interface, behavior
scripting, control flow, java/javascript interface, etc.
The plugin for Netscape, and the ActiveX control for IE are called
"HyperActive" and they let you deploy 3D audiovisual multiuser content in
web pages. Basically, it's a general purpose multiplayer game engine
wrapped in a little (<400K) plugin.
Anyway, I thought that since many of you helped me puzzle out the design of
this language, you might want to see the result.
The plugin is free, as is the SDK (a manual which isn't really done yet,
exporter, utilities & sample programs). You'll find it at:
http://www.kaon.com/SDK
Thanks again for all your help!
-Joshua Smith
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)
From tyler at infinet.com Fri Sep 17 22:11:28 1999
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun 7 17:15:10 2004
Subject: XML in the real world... Was "Re: Another look atnamespaces"
References: <199909171111.MAA14708@nag.co.uk> <4.1.19990917094330.0251cd90@mail.webgeek.com>
Message-ID: <37E29FF3.94799E49@infinet.com>
Ann Navarro wrote:
> It's assertions like this that honestly confuse me. WWW content,rendered on
> today's HTML browsers, cares not a whit about namespaces, so how does
> having 3 complicate your life more than 1? We effectively have "0" since
> the browsers don't use, acknowledge, or appreciate the namespace.
This is true now for HTML itself now, but aside from making browsers more bloated
than they already are. What you end up having to do in practice anyways is map
each P element from each namespace to some sort of element object in the document
tree rather than just have one P element. How about 3 new versions of XHTML in say
XHTML 2.0. Then you have 6 different namespaces to deal with, rather than just
one.
You will have code that says:
if (namespace.equals("XHTML_1.0_STRICT")) {
processXHTML10Element("elementName");
}
else if (namespace.equals("XHTML_2.0_STRICT")) {
processXHTML20Element("elementName");
}
Every time you create a new version of XHTML, previous versions are in effect no
longer backwards compatible unless you map the elements from the old namespace to
the new namespace which really is bad practice and a hack.
HTML 3.0 browsers could read HTML 2.0 content since HTML 3.0 inherited the
properties of HTML 2.0. But by putting everything in its own namespace you are
really saying that there will no longer be any sort of inheritance. If you can't
see the potential for code bloat, let alone dangerous hacks that HTML engines will
employ just to glue everything together, then I don't know what to say.
On a related note, if anyone looks at the current draft of XSLT, it is a very nice
piece of work, even though I wish that "Namespaces in XML" was removed from it and
replaced with something different to handle the namespaces issue. One reason it is
a nice piece of work is that through the hard work of James Clark, he has written
a proof of concept implementation of each draft that he calls XT. Though I have
never been present at any of the XSLT WG's, I am sure that Mr. Clark has raised
many issues that would otherwise never have been raised if he had not actually
implemented the most recent working drafts into XT. Perhaps, this should be done
with XHTML even though a prototype implementation is actually a lot more work than
writing an XSLT processor (may take at least three people). This may seem like a
waste of resources, but I think it would really help out the HTML WG in separating
theory from reality.
> > Also, the fact that 99% of
> >the posts on this
> >list aside from Ann's are from men who need to get out more (including
> >myself) makes it all
> >the more encouraging to see someone like Ann challenge the incoming flood of
> >testosterone that
> >swamps this mailing list (-:
>
> Would it help to know that in my "previous life" (of most of my 20s), I
> spent nearly 10 years in the radio control room at the police department,
> effectively telling 30-50 men where to go all night? ;)
Oh so I guess you are used to the overwhelming male atmosphere here. Well at least
you had a large pool of men in uniform to date whenever you wanted to back then.
Now you just have the option of having cyber-sessions with us XML-DEVers (-:
Tyler
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)
From bpaul at wbtsystems.com Fri Sep 17 22:44:43 1999
From: bpaul at wbtsystems.com (Barry Paul)
Date: Mon Jun 7 17:15:10 2004
Subject: On a more pleasant note
In-Reply-To: <14306.26269.359383.260896@localhost.localdomain>
Message-ID: <001e01bf014e$24509180$8e5ca3ce@mumble.wbtsystems.com>
[using CDATA to hide HTML]
>
> Actually, it's by far the worst of the three. When someone is
> actually generating the markup (as Tim is in this case), then there
> are immense advantages to being able to process the HTML with the same
Well, I was thinking of a situation where the HTML was not being
generated by Tim. In this case there is more than a possibility
that the HTML will not be well formed or valid. In this case
#1 would not work.
> #2 is also pretty awful, but at least it won't blow up if the HTML
> happens to contain the "]]>" character sequence (say, as an
> emoticon?).
I agree, all the solutions are pretty horrible. Have you any other
suggestions as to how "real-world" HTML could be encapsulated in
XML?
-----
Barry
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)
From david at megginson.com Fri Sep 17 22:48:55 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:10 2004
Subject: On a more pleasant note
In-Reply-To: <001e01bf014e$24509180$8e5ca3ce@mumble.wbtsystems.com>
References: <14306.26269.359383.260896@localhost.localdomain>
<001e01bf014e$24509180$8e5ca3ce@mumble.wbtsystems.com>
Message-ID: <14306.29024.414449.468797@localhost.localdomain>
Barry Paul writes:
> I agree, all the solutions are pretty horrible. Have you any other
> suggestions as to how "real-world" HTML could be encapsulated in
> XML?
That's a separate question -- real-world (non-XML) HTML can be
encapsulated reasonably in three ways:
1. Escape '<', '>', and '&' (assuming that there are no non-XML
characters like form-feed).
2. Uuencode the whole mess.
3. Put it in a separate file and point to it.
The second and third options work for anything -- you can use them for
graphics, MP3s, or what-have-you.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From tyler at infinet.com Fri Sep 17 22:55:44 1999
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun 7 17:15:10 2004
Subject: On a more pleasant note
References: <3.0.32.19990917105301.012183e0@pop.intergate.bc.ca>
Message-ID: <37E2AA89.A65664C9@infinet.com>
Tim Bray wrote:
> There's been a lot of angst around here recently. On a countervailing note:
> I am building this big hairy complicated app in which a web server traverses
> an extremely complex database, extracts some dense information structures,
> sends them to a client, and the client does some nifty rendition tricks.
>
> Building the database is hard. Traversing the database is hard. Doing the
> rendition on the client is hard. But generating the message on the server
> takes one little C subroutine (printf calls, nothing fancy), and extracting
> the information from it on the client (using an XML parser, it doesn't
> matter which) is one little Java routine. The client-side worked first
> time, the server-side on the second (I wasn't escaping some &'s properly,
> which the XML parser on the client caught first time through). All the
> rest is done by Apache and Linux and Windows and TCP/IP and HTTP and
> java.net.URL and the XML parser. It took maybe an hour to build both sides.
>
> Seems to me that this is the right way to build distributed applications.
For your problem domain of a traditional client/server app, yah this setup seems to work great
for you. Since most people building web applications will likely have a setup that mirrors
yours, your success story is reassuring. On the other hand, I am using XML for an entirely
different distributed application some might consider groupware oriented that does not depend
on some 24/7 server running all the time. Probably a lot more complicated than your 2 hour
setup, but for this app XML I think has been a wonderful complement to object serialization as
it is a much nicer data format for potential application interoperability later down the line.
> -Tim
>
> PS: In the XML I'm sending out from the server, I am embedding some human
> readable text encoded, obviously enough, in HTML. What would be a good way
> to distinguish it from my own XML tags so that I can extract it and feed
> it to the HTML renderer? Any suggestions?
Well there is always the comment hack. If a comment starts with some magic string you define,
then simply trim off the rest of the data in the comment as your HTML. You will of course need
to make sure that you handle nested comments appropriately. Of course I am sure you have
already thought of this as this I guess is pretty obvious and there are probably obvious
pitfalls I can't think off the top of my head right now. But if I had 30 seconds to find a
solution, that would be what I would try first (-:
Tyler
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)
From john.tigue at tigue.com Fri Sep 17 23:02:31 1999
From: john.tigue at tigue.com (John Tigue)
Date: Mon Jun 7 17:15:10 2004
Subject: SOAP non-opera (was CNET on XHTML) [re-send]
Message-ID: <000601bf0158$e34f5440$788410d2@tigue.oz.net>
I no longer invest any of my time in "RPC over HTTP via XML". So,
this message is related to politics not technology. If, for some
crazy reason, you're looking for a technical discussion (because this
is xml-dev) then get out now.
Don Park wrote:
> The article was updated with Ann's comment added so it is
> more balanced now although the result is the same: there is
> trouble brewing for W3C. Since I am fairly certain that W3C
> will ignore all the arguments and concerns raised against
> three namespaces, I believe the divide between W3C and
> XML-DEV will continue to widen.
>
> I wonder why the SOAP spec was submitted to IETF rather
> than W3C? A new trend of sort?
Over the last few years, Microsoft has repeatedly submitted DCOM
specs to the IETF. SOAP is just DCOM over HTTP. So I do not feel
that Microsoft's actions with regards to SOAP can be used as
evidence to support "a new trend" in Microsoft's behavior as it
relates to the W3C and the IETF.
Here's an example of Microsoft submitting DCOM to the IETF, at
http://www.ietf.org/mail-archive/ietf/msg00139.html
Quoting modulo formatting:
6. There were 152 Internet-Draft Actions during the month of
January, 1998:
[...]
Distributed Component Object Model Protocol --
DCOM/1.0
I do believe that SOAP will be discussed within the W3C. For
example, the HTTP-NG Reading List at
http://www.w3.mag.keio.ac.jp/Protocols/HTTP-NG/ReadingList.html
contains a reference to a DCOM spec. Quoting:
The DCOM protocol (DCOM ORPC - issued as an IETF Internet draft
"draft-brown-dcom-v1-spec-01.txt". Expired, May 1996
Also, Microsoft has representation in the appropriate W3C WG, the
HTTP-NG Protocol Design Group (PDG). So I suspect that SOAP will
come up during the group's meetings. Although I was briefly a
member of the HTTP-NG PDG WG, I have not been active in the W3C
since I left DataChannel almost a year ago so this is all
conjecture (hopefully without confidentiality concerns).
That said, I hope to never write another word about XML-RPC, SOAP,
WebBroker, or their ilk.
/John
--
John Tigue
john.tigue@tigue.com
http://www.tigue.com
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)
From timbl at w3.org Sat Sep 18 00:18:15 1999
From: timbl at w3.org (Tim Berners-Lee)
Date: Mon Jun 7 17:15:11 2004
Subject: Another look at namespaces
Message-ID: <03ed01bf015a$dc243cb0$a60a1712@col.w3.org>
-----Original Message-----
From: David Megginson
To: XML-DEV
Cc: Tim Berners-Lee
Date: Friday, September 17, 1999 3:23 PM
Subject: Re: Another look at namespaces
>Tim Berners-Lee writes:
>
> > That is not useful. I realize that the word "Namespace" (as the
> > end result fo the discussions of modules or docuemnt types or
> > vocabularies or...) may be an english word which does not convey
> > this, but a a namespaces is a language: a set of names plus a set
> > of syntactic constraints plus - to be useful - a meaning shared by
> > writer and recipient.
>
>As (I think) Tim is arguing later in his message, a Namespace is a
>component of a vocabulary: specifically, it's the mechanism that XML
>documents use to represent (and disambiguate) the names that are part
>of a vocabulary, but, as Rick argues, it's not the vocabulary itself.
>
>Since Paul Prescod mentioned Chomsky, I'll mention Saussure: like
>written or spoken words, a namespace-qualified name is a pure lang="fr">signifiant without any lang="fr">signifi?e .
There is a signifi?e, unless the namespace is useless.
To design a namespace with no meaning is a possible excercise
but as documents written in such a namespace would have no meaning.
The namespaces spec doesn't tell you how to describe the
meaning of a name. But that does *not* mean that it should have none.
>For example, the signifier "{http://www.megginson.com/ns/}apt" can be
>represented by Namespaces. The signified (say, "a valid ICAO airport
>code") cannot be represented by Namespaces, but for now will probably
>be represented in human-readable documentation and hard-coded in
>applications.
>
>I guess that a machine-readable schema could constrain the element to
>contain up to four alphanumeric characters, but who cares, really?
> My
>application still has to know somehow that it's an airport code and it
>has to know what it wants to do with airport codes (sell you a ticket?
>give you driving directions? tell you that the document contains a
>match for the code you were looking for?).
But once your application can do that with a
http://www.megginson.com/ns#element-apt
then an RDF assertion that
http://www.blee.com/ns2 is-subset-of http://www.megginson.com/ns
will allow your application to know automatically
how to process airport codes in my vocabulary.
I just declared mine to be a subset of yours.
Or I might in a schema want to assert that
http://www.blee.com/ns2#element-airportcode is-equivalent-to
http://www.megginson.com/ns#element-apt
>David
Tim
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)
From Marc.McDonald at Design-Intelligence.com Sat Sep 18 00:21:40 1999
From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com)
Date: Mon Jun 7 17:15:11 2004
Subject: Another look at namespaces
Message-ID: <4454C011BDE5D211B6C800609776E5402682E3@master.design-intelligence.com>
> >There is no W3C method to define a namespace as list of names.
>
> There is an xml-schema spec in the works destined to do that
> and more.
>
> One can either take the existing specs at face value at any point in
> history, and not complain about the lack of functionality. Or you can
> work with
> the model which you forsee you can
>
In the works does not equal recommendation. In particular, why should XHTML
go off and decide a mechanism to solve a problem which is a general XML
problem and is being worked on by the schema group?
XHTML should define no namespace at all and await schemas.
The existing namespace spec merely disambiguates. You can't declare the list
of valid names. You can't declare the valid structure. You don't have to use
a namespace unless an element is ambiguous.
If schemas end up extending namespaces (to have a reference to a schema
required for instance), then fine. But, XHTML should not be making that
decision.
Also, as noted in other messages, browsers don't use namespaces. So, there
may need to be 2 versions of every XHTML document - one for browsers and one
for XML parsers. I thought the point of XHTML was an XML compatible version
of HTML. That would mean no implicit ending of elements, for instance. An
XHTML document should be acceptable to an HTML browser and an XML 1.0
parser.
It looks to me like the use of namespaces makes that impossible. Is
a browser going to recognize strict:p? And if XHTML documents for browsers
don't use namespaces why do we have to use them with XML?
Marc B. McDonald
Principal Software Scientist
Design Intelligence, Inc.
1111 Third Avenue, Suite 1500
Seattle, WA 98101
marc.mcdonald@design-intelligence.com
Ph: 206.343-7797
Fax: 206.343.7750
http://www.design-intelligence.com
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)
From david at megginson.com Sat Sep 18 00:30:59 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:11 2004
Subject: Another look at namespaces
In-Reply-To: <03ed01bf015a$dc243cb0$a60a1712@col.w3.org>
References: <03ed01bf015a$dc243cb0$a60a1712@col.w3.org>
Message-ID: <14306.49588.271748.587016@localhost.localdomain>
Tim Berners-Lee writes:
> The namespaces spec doesn't tell you how to describe the
> meaning of a name. But that does *not* mean that it should have none.
But I didn't suggest that at all (sorry for any confusion) -- I merely
suggested that the Namespace-qualified name itself is just a
signifier. The signified is something and somewhere else. I'm fairly
certain that we agree on this point.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From Marc.McDonald at Design-Intelligence.com Sat Sep 18 00:39:20 1999
From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com)
Date: Mon Jun 7 17:15:11 2004
Subject: A compromise?
Message-ID: <4454C011BDE5D211B6C800609776E5402682E4@master.design-intelligence.com>
David Brownell wrote:
> Don Park wrote:
> >
> > What if we came up with a way to associate a schema with any element
> without
> > using namespace? Would it address the real concerns of the HTML WG?
>
> I'm also curious why the HTML WG should care, since (X)HTML has
> only DTDs (currently three of them) for which there's already
> a standard association technique:
>
> '-//W3C//DTD XHTML 1.0 Transitional//EN'
> 'http://www.w3.org/TR/xhtml1/DTD/transitional.dtd'>
>
> Seems to me that the best compromise is to stick exclusively to what
> is already accepted -- ruling out schemas.
>
EXACTLY. Leave the work to the schema group to solve the general
problem for all XML, not a special solution for XHTML which may or may not
end up being compatible.
The only argument I've seen presented is if you want to use HTML in
your XML document. It is suggested to declare the HTML namespace and prefix
the elements you use. Since HTML elememts are mixed with other document
elements, the DOCTYPE declaration wouldn' t work.
Actually it would since the DTD referenced would have to contain the
XHTML element declarations (or use ANY). If it included the declarations
then there would be no ambiguity - validation does not recognize namespaces
so H1 would be declared without a prefix. If it were declared with a prefix,
then it would be establishing a standard prefix and any application could
just as easily recognize 'strictH1' as 'strict:h1'.
The reuse of DTD content is a general XML issue and should also be
solved generally. I'm not sure which group has responsiblity for it (I'm
guessing schemas).
> Marc B. McDonald
> Principal Software Scientist
>
> Design Intelligence, Inc.
> 1111 Third Avenue, Suite 1500
> Seattle, WA 98101
> marc.mcdonald@design-intelligence.com
> Ph: 206.343-7797
> Fax: 206.343.7750
>
> http://www.design-intelligence.com
>
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)
From tbray at textuality.com Sat Sep 18 01:00:51 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun 7 17:15:11 2004
Subject: Another look at namespaces
Message-ID: <3.0.32.19990917160313.00ca0b30@pop.intergate.bc.ca>
At 09:18 AM 9/17/99 -0400, Tim Berners-Lee wrote:
>From: Tim Bray
>>Among other things, I don't believe that most
>>interesting namespaces *have* definitive information, but have semantics
>>that are communicated via some messy combination of schemas, stylesheets,
>>prose documentation, and running code.
>
>We either have a different use of words or a very serious
>problem. Whereas with natural langauge, meanings change and
>grow and everyone has slightly different associations with a word,
>in computer languages we need to build on top of XML we need
>to have the ability to define meaning precicely in terms of
>other existing languages.
Actually, Tim B-L and I are both advocates of moving as much semantics as
possible from idiosyncratic impenetrable procedural code and woolly forests
of prose into declarative schemas so that you can start to use some
knowledge rep tricks and do a bit of meaning-discovery, not just the
resource-discovery enabled by the current Web. This is what Tim calls
"the semantic web" in his platform speeches, and its foundation is
RDF and RDF style schemas. I'm onside with this.
Perhaps the disagreement (if any) is on the degree to which this
is possible. There are going to be lots of languages invented, and
while I believe that we will get increasingly better definitional
machinery as time goes on, I see no reason to believe that any of
the following are going away:
- human-readable documentation
- messy procedural code that actually does something useful with the data
- stylesheets (plural)
- related resources containing hyperlink networks
- related resources containing RDF assertions in some vocabulary
- transformation specs along the lines of XSLT
and so on and so on.
What bothers me is the notion that among all these things, the schema
is somehow privileged and special. I think that which of the above
laundry-list you care most about is very highly application-dependent,
data-dependent, and rather wholly unpredictable in the general case.
I suspect that the proportion of real-world applications that actually
use the schema at run-time will be moderate at best - schemas come more
usefully into play in application design, authoring support, and so on.
Perhaps Tim B-L thinks that this proportion will in fact be quite high?
This is a reasonable disagreement, and we've all been fooled by
technology enough times to have learned humility.
So.......... where do we still have disagreements with concrete
short-term implications?
1. I'm convinced that the namespace mechanism, while it's useful
for what it is, is hopelessly inadequate as a tool for direct
mapping between instances and schemas. We need at least one level
of indirection, i.e. the packaging work that's hanging fire in
the W3C XML activity.
2. For this reason, I think that the correspondence between
namespaces and DTDs in XHTML 1.0 PR doesn't do a good job of meeting
the needs of either people who need schema discrimination or of
people who think HTML-is-HTML.
3. I am astonished and disappointed that the W3C still can't bring
itself to publish a 3-line note saying that for those who see
HTML just as HTML, and who want to mix & match those tags with
others, they should use the following URI as a namespace name for
HTML:
-Tim
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)
From ann at webgeek.com Sat Sep 18 01:28:45 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:11 2004
Subject: XML in the real world... Was "Re: Another look
atnamespaces"
In-Reply-To: <37E29FF3.94799E49@infinet.com>
References: <199909171111.MAA14708@nag.co.uk>
<4.1.19990917094330.0251cd90@mail.webgeek.com>
Message-ID: <199909172330.XAA51828@out4.prserv.net>
At 04:09 PM 9/17/99 -0400, Tyler Baker wrote:
> How about 3 new versions of XHTML in say
>XHTML 2.0. Then you have 6 different namespaces to deal with, rather than
just
>one.
Except there aren't 3 new versions of XHTML in the next iteration.
There's 1. XHTML 1.1 (see public working drafts)
>Oh so I guess you are used to the overwhelming male atmosphere here. Well
at least
>you had a large pool of men in uniform to date whenever you wanted to back
then.
Hrm. Cops or crooks, what would you pick? ;)
>Now you just have the option of having cyber-sessions with us XML-DEVers (-:
Don't think my husband ( http://www.basicguru.com/navarro/ ) would approve
much ;)
Ann
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)
From ann at webgeek.com Sat Sep 18 02:05:02 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:11 2004
Subject: Another look at namespaces
In-Reply-To: <4454C011BDE5D211B6C800609776E5402682E3@master.design-intel
ligence.com>
Message-ID: <199909180007.AAA51248@out4.prserv.net>
At 03:24 PM 9/17/99 -0700, Marc.McDonald@Design-Intelligence.com wrote:
>. In particular, why should XHTML
>go off and decide a mechanism to solve a problem which is a general XML
>problem and is being worked on by the schema group?
We didn't decide someone else's problem. We took a work in progress and
used it as the basis of *one* aspect (out of several) for our decision on
the namespace issue.
Ann
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)
From b.laforge at jxml.com Sat Sep 18 03:17:52 1999
From: b.laforge at jxml.com (Bill la Forge)
Date: Mon Jun 7 17:15:11 2004
Subject: A working alternative to XML Data Binding (An Open Source Release Notice)
Message-ID: <002401bf0174$327c3c20$c8a8a8c0@thing1.jxml.com>
Having an easy way to convert XML documents to Java objects is (IMHO)
a great idea. But I don't like code generators. And XML Data Binding looks
like yet another reason to tie a project to a particular vendor's proprietary
IDE.
MDSAX could be an answer, but it has been difficult to understand and
harder to use. But that is no longer true. MDSAX 2.0 has been reworked
with the intent of making it easy to use.
Like XML Data Binding, MDSAX uses a schema to drive the conversion
of XML documents into application-specific Java objects. But MDSAX
is designed to work with existing objects (like Swing components), rather
than forcing a programmer to subclass generated code.
You might like the new documentation, too: http://www.jxml.com/mdsax/index.html
Bill la Forge, CTO
JXML, Inc.
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)
From ann at webgeek.com Sat Sep 18 03:09:23 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:11 2004
Subject: Another look at namespaces
In-Reply-To: <4454C011BDE5D211B6C800609776E5402682ED@master.design-intel
ligence.com>
Message-ID: <199909180111.BAA85878@out4.prserv.net>
At 05:58 PM 9/17/99 -0700, Marc.McDonald@Design-Intelligence.com wrote:
>
>> At 03:24 PM 9/17/99 -0700, Marc.McDonald@Design-Intelligence.com wrote:
>>
>> >. In particular, why should XHTML
>> >go off and decide a mechanism to solve a problem which is a general XML
>> >problem and is being worked on by the schema group?
>>
>> We didn't decide someone else's problem. We took a work in progress and
>> used it as the basis of *one* aspect (out of several) for our decision on
>> the namespace issue.
>>
>> Ann
>>
>> But that is jumping the gun - part of a work in progress is in a proposed
>> recommendation.
The key phrase in there is "one aspect" -- and we're still not *using*
schemas, we're addressing the possibility that this may happen, as well as
dealing with the other use cases described in Steven's message.
Ann
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)
From Marc.McDonald at Design-Intelligence.com Sat Sep 18 02:57:08 1999
From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com)
Date: Mon Jun 7 17:15:11 2004
Subject: Another look at namespaces
Message-ID: <4454C011BDE5D211B6C800609776E5402682ED@master.design-intelligence.com>
> At 03:24 PM 9/17/99 -0700, Marc.McDonald@Design-Intelligence.com wrote:
>
> >. In particular, why should XHTML
> >go off and decide a mechanism to solve a problem which is a general XML
> >problem and is being worked on by the schema group?
>
> We didn't decide someone else's problem. We took a work in progress and
> used it as the basis of *one* aspect (out of several) for our decision on
> the namespace issue.
>
> Ann
>
> But that is jumping the gun - part of a work in progress is in a proposed
> recommendation.
>
> Things can change before it is a recommendation, particularly when the
> only published document on schemas is a requirements document, not even a
> working draft or proposed recommendation status.
>
> I can show you a lot of XML files that used the wrong capitalization for
> XML declarations because it was changed with the official 1.0 release. XSL
> has changed between versions. The URI for RDF has changed with the final
> release.
>
> I seem to remember some rather explicit language in the status of document
> section of working drafts:
>
> "This is a draft document and may be updated, replaced or obsoleted by
> other documents at any time. While we do not anticipate substantial
> changes, we still caution that further changes are possible. It is
> inappropriate to use this document as reference material or to cite it as
> other than 'work in progress'".
>
I would think using something that hasn't even reached 'work in progress'
status and putting it in a proposed recommendation is far more problematic
than using a working draft as reference material.
Again, from the rationales I've seen, you aren't really using namespaces as
defined by the spec. You are trying to define XML modules which is not part
of namespaces but I would think are part of the schema group's task.
I don't mind the XHTML DTD broken into modular pieces, just don't talk about
namespaces at all. The general XML solution will apply equally well to XHTML
modules when it is developed.
Marc B. McDonald
Principal Software Scientist
Design Intelligence, Inc.
1111 Third Avenue, Suite 1500
Seattle, WA 98101
marc.mcdonald@design-intelligence.com
Ph: 206.343-7797
Fax: 206.343.7750
http://www.design-intelligence.com
P. S. Cops or Crooks? Isn't it more important which you choose than us ;)
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)
From Marc.McDonald at Design-Intelligence.com Sat Sep 18 03:33:19 1999
From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com)
Date: Mon Jun 7 17:15:11 2004
Subject: Another look at namespaces
Message-ID: <4454C011BDE5D211B6C800609776E5402682EF@master.design-intelligence.com>
> : RE: Another look at namespaces
>
> At 05:58 PM 9/17/99 -0700, Marc.McDonald@Design-Intelligence.com wrote:
> >
> >> At 03:24 PM 9/17/99 -0700, Marc.McDonald@Design-Intelligence.com wrote:
> >>
> >> >. In particular, why should XHTML
> >> >go off and decide a mechanism to solve a problem which is a general
> XML
> >> >problem and is being worked on by the schema group?
> >>
> >> We didn't decide someone else's problem. We took a work in progress and
> >> used it as the basis of *one* aspect (out of several) for our decision
> on
> >> the namespace issue.
> >>
> >> Ann
> >>
> >> But that is jumping the gun - part of a work in progress is in a
> proposed
> >> recommendation.
>
>
> The key phrase in there is "one aspect" -- and we're still not *using*
> schemas, we're addressing the possibility that this may happen, as well as
> dealing with the other use cases described in Steven's message.
>
> Ann
>
"... we're addressing the possiblity that this may happen ..."
I just don't see why a proposed recommendation should address a
possibility in an area that hasn't even had a working draft released. Just
don't address it until it is a recommendation and save us all this time.
Which Steven and which message? There have been so many messages and
I didn't see it in the Sept archive.
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)
From ann at webgeek.com Sat Sep 18 03:39:23 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:11 2004
Subject: Another look at namespaces
In-Reply-To: <4454C011BDE5D211B6C800609776E5402682EF@master.design-intel
ligence.com>
Message-ID: <199909180141.BAA107642@out4.prserv.net>
At 06:36 PM 9/17/99 -0700, Marc.McDonald@Design-Intelligence.com wrote:
> "... we're addressing the possiblity that this may happen ..."
> I just don't see why a proposed recommendation should address a
>possibility in an area that hasn't even had a working draft released. Just
>don't address it until it is a recommendation and save us all this time.
Perhaps I'm not being clear. That was only *one aspect* of the decision to
use three namespaces. Not the only one. The others were also compelling
enough to result in that decision. Even if we "don't address" schemas, the
other use cases are still there, and the decision is the same. It is not a
matter of only looking at schemas.
> Which Steven and which message? There have been so many messages and
>I didn't see it in the Sept archive.
Steven Pemberton, HTML WG Chair, providing the official rationale statement.
Ann
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)
From simonstl at simonstl.com Sat Sep 18 04:49:37 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:11 2004
Subject: Signifiers/Namespaces (was Re: Another look at namespaces)
In-Reply-To: <14306.49588.271748.587016@localhost.localdomain>
References: <03ed01bf015a$dc243cb0$a60a1712@col.w3.org>
<03ed01bf015a$dc243cb0$a60a1712@col.w3.org>
Message-ID: <199909180251.WAA22043@hesketh.net>
Hmm... structuralism... seems appropriate here.
Maybe we can say that:
a local name is a partial signifier, like having part of a (person's) name
a qualified name is a complete signifier
a schema is a set of rules describing how signifiers can contain other
signifiers, and defines a set of signifiers.
This still leaves us needing something else to connect signifiers to
_signifieds_ - which we don't have yet. A schema, except perhaps in the
documentation end of it, still doesn't do that.
RDF is one possibility that's been suggested for connecting signifiers to
signified, and XML packaging has been suggested as another. Right now, it
seems like we're spending a lot of time manipulating signifiers and hoping
that the connection to the signified is obvious. Which it is - except that
everyone's obvious is different.
Have to stop home and pick up that battered copy of Saussure. Can't say I
was ever fond of Chomsky.
At 06:33 PM 9/17/99 -0400, David Megginson wrote:
>Tim Berners-Lee writes:
> > The namespaces spec doesn't tell you how to describe the
> > meaning of a name. But that does *not* mean that it should have none.
>
>But I didn't suggest that at all (sorry for any confusion) -- I merely
>suggested that the Namespace-qualified name itself is just a
>signifier. The signified is something and somewhere else. I'm fairly
>certain that we agree on this point.
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From abrahams at valinet.com Sat Sep 18 04:10:55 1999
From: abrahams at valinet.com (Paul W. Abrahams)
Date: Mon Jun 7 17:15:11 2004
Subject: Unicode surrogate block in XML?
Message-ID: <37E2F5FC.7B90D7F8@valinet.com>
Tony Graham (tgraham@mulberrytech.com)
Fri, 17 Sep 1999 01:15:51 -0400 (EST)
>> In any XML document, you can make numeric references to any Unicode
character in the range #x10000 to #x10FFFF (as well as to any other
legal character number). These references are independent of the
encoding used in the XML document. <<
Is it really correct to refer to #x10FFFF, say, as a Unicode
character, since Unicode characters are limited to 16 bits? I'd think
it's necessary here to refer to that as a UCS-4 character.
>> The sequence of #xD800 #xDC00 is the two Surrogate code values that
address #x10000. That four-byte sequence may occur in a UTF-16
encoded file to represent #x10000. In contrast, "��" in
an XML document is two illegal character references in a row. <<
I've been trying to fathom the distinction between Unicode and UTF-16,
if there is one, and how these in turn relate to the UCS-2 encoding of
ISO 10646. There's also the question of whether an XML document can
be stored directly in Unicode, or whether instead it must be stored in
either UTF-8 or UTF-16, as Section 2.2 seems to imply when it says
``all XML processors must accept the UTF-8 and UTF-16 encodings of
10646''. The latter appears to be the case; but if it isn't, then
how would an XML document be stored directly in Unicode? I've
pondered both Appendix C of the Unicode Standard and the relevant part
of the FAQ on the Unicode website, and I'm still unclear about all of
this. (By the way, the FAQ erroneously refers to UTF as the Unicode
Transformation Format rather than the UCS transformation format.)
In any event, thanks, Tony, for your very enlightening response to my
original query.
Paul Abrahams
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)
From fujisawa at the.canon.co.jp Sat Sep 18 05:41:49 1999
From: fujisawa at the.canon.co.jp (Jun Fujisawa)
Date: Mon Jun 7 17:15:11 2004
Subject: C/C++ DOM implementation using expat
In-Reply-To: <001801bf005a$0c4c3200$1ff96d8c@NT.JELLIFFE.COM.AU>
Message-ID:
At 11:42 PM +0800 99.9.16, Rick Jelliffe wrote:
> If anyone is working on a C DOM implementation using expat,
> there is a C interface definition for DOM (.h) available at
> http://www.ascc.net/~ricko/src/dom_interface.h
> which they might find convenient to use (contributions and suggestions
> welcome).
I find the C interface definition for DOM very interesting.
I don't have any idea on which level of conformance to CORBA mapping
rules might be important, here is my questions and comments.
- why DOM_Object is not defined as void*?
- how about defining DOM_Environment as follows:
typedef struct DOM_Environment {
CORBA_exception_type _major;
DOM_Exception;
} DOM_Environment;
- DOM_String could be simply defined as CORBA_wchar*.
- two underscores are not needed for mapping operations.
--
Jun Fujisawa
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)
From tyler at infinet.com Sat Sep 18 06:07:11 1999
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun 7 17:15:12 2004
Subject: XML in the real world... Was "Re: Another lookatnamespaces"
References: <199909171111.MAA14708@nag.co.uk>
<4.1.19990917094330.0251cd90@mail.webgeek.com> <199909172330.XAA51828@out4.prserv.net>
Message-ID: <37E31044.156154BC@infinet.com>
Ann Navarro wrote:
> At 04:09 PM 9/17/99 -0400, Tyler Baker wrote:
>
> > How about 3 new versions of XHTML in say
> >XHTML 2.0. Then you have 6 different namespaces to deal with, rather than
> just
> >one.
>
> Except there aren't 3 new versions of XHTML in the next iteration.
>
> There's 1. XHTML 1.1 (see public working drafts)
OK, well I suppose I was confused. Nevertheless, every new version of XHTML will give
programmers the choice of having the HTML processor map elements from different namespaces
(each version of XHTML) to a single common element (a hack) or else have different HTML
processors for each namespace (bloat). There is no concept of inheritance whatsoever, which
although not absolutely necessary, I think would be good practice considering the history of
the web community's adoption of new HTML specs as they come out the door.
> >Oh so I guess you are used to the overwhelming male atmosphere here. Well
> at least
> >you had a large pool of men in uniform to date whenever you wanted to back
> then.
>
> Hrm. Cops or crooks, what would you pick? ;)
Depends on the cop or the crook. Even then crooks might be more attractive than some of the
markup enthusiasts in this forum.
> >Now you just have the option of having cyber-sessions with us XML-DEVers (-:
>
> Don't think my husband ( http://www.basicguru.com/navarro/ ) would approve
> much ;)
Hey what he does not know won't hurt him. Just don't let him read the blasphemous content that
gets posted to this listserv or he might develop a fetish to posting arguments about
specifications which at the end of our lives will probably be a meaningless set of events in
history that are no more relevant than taking a drive on a Sunday afternoon with the wife in
kids (or in your case your husband and any children you may have that are not already grown
and out of the house).
On a lighter note, who would of ever thought many years back that a simple network protocol
for hypertext developed by Tim B-L would evolve into the greatest protocol ever for adults to
waste their lives away in chat rooms talking dirty to each other while exchanging nude
pictures of each other all on Yahoo and other portal sights with free chat, email, and web
accounts. Just think that all of this debating about XHTML and namespaces is really just about
the best data format to deliver porn to the masses.
So why I and others waste my life in the dark art of internet programming so that marriages
can be wrecked by internet addiction and kids can be desensitized by internet porn, I guess I
will never know without some deep reflection. Nevertheless, I am pretty sure that 5-10 years
down the line the W3C will be a dot in the annals of web history because it failed to listen
to the devoted developers of the internet community about their concerns on W3C
recommendations no matter how stupid or trivial they may seem at the time. Hopefully in the
meantime another standards organization will arise that fills the void left by the W3C that
many of us developers feel exists when we try and think of a relevant internet standards
organization with financial backing.
Well off to bigger and better things (-:
Tyler Baker
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)
From tgraham at mulberrytech.com Sat Sep 18 06:39:27 1999
From: tgraham at mulberrytech.com (Tony Graham)
Date: Mon Jun 7 17:15:12 2004
Subject: Unicode surrogate block in XML?
In-Reply-To: <37E2F5FC.7B90D7F8@valinet.com>
References: <37E2F5FC.7B90D7F8@valinet.com>
Message-ID: <14307.5845.120000.679232@menteith.com>
At 17 Sep 1999 22:16 -0400, Paul W. Abrahams wrote:
> Tony Graham (tgraham@mulberrytech.com)
> Fri, 17 Sep 1999 01:15:51 -0400 (EST)
>
> >> In any XML document, you can make numeric references to any Unicode
>
> character in the range #x10000 to #x10FFFF (as well as to any other
> legal character number). These references are independent of the
> encoding used in the XML document. <<
>
> Is it really correct to refer to #x10FFFF, say, as a Unicode
> character, since Unicode characters are limited to 16 bits? I'd think
> it's necessary here to refer to that as a UCS-4 character.
The Unicode Standard started out with the design principle that all
characters have a uniform width of 16 bits. The expectation was that
the 65,000 or so characters that you can address with 16 bits would
far exceed the requirements. However, reality intruded, and the
practicalities (and possibly the political realities) of defining a
universal character set has meant that there are more characters to be
defined than can fit in a 16-bit address space.
Unicode 2.0, published in 1996, defines the Surrogate block and a
mechanism for using two code values from the surrogate block to
address over one million extra characters.
The Unicode Standard, Version 2.0, supports surrogates, but doesn't
quite know what to do about them. Section 3.7 of the Unicode
Standard, Version 2.0, defines surrogates, and they are mentioned
again in section C.3, but you're left with the impression that they
and UTF-16 are really an ISO/IEC 10646 thing. UTF-16 was initially
defined in Amendment 1 of ISO/IEC 10646-1:1993, so it wasn't far off
the mark.
Planes 15 and 16 are reserved for private use, so there's been a
legitimate use for surrogates, or, more broadly, for using characters
outside Plane 0, since 1996.
Since 1996, however, there have been numerous proposals for scripts to
be included in the Unicode Standard and ISO/IEC 10646, and many of
these are slated for definition in Plane 1, i.e. they'll need more
than 16 bits to address the characters. As far as I know, none have
been assigned code values yet, but it won't be too long after the
release of the Unicode Standard, Version 3.0, and ISO/IEC
10646-1:2000. Furthermore, Plane 2 is reserved as the CJK Unified
Ideographs Supplementary Plane, and it already has 41,000 characters
lined up for inclusion.
> >> The sequence of #xD800 #xDC00 is the two Surrogate code values that
>
> address #x10000. That four-byte sequence may occur in a UTF-16
> encoded file to represent #x10000. In contrast, "��" in
>
> an XML document is two illegal character references in a row. <<
>
> I've been trying to fathom the distinction between Unicode and UTF-16,
> if there is one, and how these in turn relate to the UCS-2 encoding of
There isn't one anymore. The Unicode Standard used to say that it
corresponded to UCS-2, but now it has embraced UTF-16 (and given us
UTF-16BE and UTF-16LE for big-endian and little-endian representations
without the BOM, respectively).
The Unicode Consortium now also defines UTF-32, which is a 32-bit
representation of the characters that you can address with UTF-16.
There is no difference between the UTF-32 representation of a
character and the UCS-4 representation of a character over the range
of characters that you can address with UTF-32. The only difference
is that when you say that your document is UTF-32, you're saying that
it comes with the Unicode character semantics and conformance
requirements rather than the different requirements of UCS-4.
UTF-8 has also come into the fold since 1996. In the Unicode
Standard, Version 2.0, UTF-8 was relegated to section A.2, but now
it's an accepted alternative for UTF-16.
> ISO 10646. There's also the question of whether an XML document can
> be stored directly in Unicode, or whether instead it must be stored in
> either UTF-8 or UTF-16, as Section 2.2 seems to imply when it says
> ``all XML processors must accept the UTF-8 and UTF-16 encodings of
> 10646''. The latter appears to be the case; but if it isn't, then
> how would an XML document be stored directly in Unicode? I've
UTF-8 and UTF-16 can encode the characters of the Unicode Standard.
The Unicode Standard used to miss an aspect compared to how some people,
e.g. some ISO standards, define a character set.
Roughly speaking, the base aspect is the character repertoire, which is
a collection of abstract characters.
The next aspect is a mapping of the character repertoire onto a set of
numbers.
The third aspect is mapping the character numbers onto some
representation as bits or bytes.
The Unicode Standard used to conflate the second and third aspects
since the character numbers are identical to the value of the 16-bit
quantities that you can use to represent the characters. Hence it
seems like a Unicode character is its 16-bit character number. This
simplification falls down when you have character numbers that you
can't express with 16-bits and you allow other bit representations for
the characters.
You'll find that the Unicode Consortium now speaks about UTF-8,
UTF-16, UTF-32, and UTF-EBCDIC. The favourite is probably still
UTF-16, but even UTF-16 isn't one 16-bit quantity to one character.
Also, the Unicode character encoding model
(http://www.unicode.org/unicode/reports/tr17/) now has five levels.
> pondered both Appendix C of the Unicode Standard and the relevant part
> of the FAQ on the Unicode website, and I'm still unclear about all of
> this. (By the way, the FAQ erroneously refers to UTF as the Unicode
> Transformation Format rather than the UCS transformation format.)
There are two definitions for UTF. ISO/IEC 10646 always defines it as
"UCS transformation format", and the Unicode Consortium mostly defines
it as "Unicode transformation format" (see section C.3 of the Unicode
Standard, Version 2.0, for an exception). They mean the same thing.
> In any event, thanks, Tony, for your very enlightening response to my
> original query.
I hope this remains enlightening, and not overwhelming.
Regards,
Tony Graham
======================================================================
Tony Graham mailto:tgraham@mulberrytech.com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9632
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================
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)
From donpark at docuverse.com Sat Sep 18 06:42:34 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun 7 17:15:12 2004
Subject: A compromise?
In-Reply-To: <37E2682E.7CEAB54B@pacbell.net>
Message-ID: <002301bf0190$d00a0820$dceefea9@w21tp>
>I'm also curious why the HTML WG should care, since (X)HTML has
>only DTDs (currently three of them) for which there's already
>a standard association technique:
But the current XML to DTD association mechanism has following problems:
1. Only one DTD per document
2. Can not specify at element granuarity
3. Can not replace DTD inline
Above restrictions makes it difficult to create composite XML documents.
Because XML namespace mechanism happens to lack above three problems, there
is a desire to equate namespace to schemas. Why not use what is already
there?
By offering a namespace-like mechanism for schema association that solves
above three problems, we can breakout of current impass.
Here is a possible (and not necessarily the best) rendition of such a
mechanism:
Comments?
Best,
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
From paul at prescod.net Sat Sep 18 08:12:29 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun 7 17:15:12 2004
Subject: Another look at namespaces
References: <006101beffba$a2984280$a60a1712@col.w3.org> <14304.11288.712453.705292@localhost.localdomain>
Message-ID: <37E257CB.75C05A3A@prescod.net>
David Megginson wrote:
>
> I believe that
>
> a. the vast majority of applications will be most concerned with #1;
> and
> b. the applications concerned only with #1 will tend to be the
> lightest-weight ones.
This sounds similar to me to a goal we set in designing XML. It's become
corrupted over time but as I recall the original goal was that XML
should not only be implement but "hackable" in the sense that you could
sit down with Perl and Awk regular expressions and do cool things with
XML documents like rename element types and so forth. I thought that
that was a bad criterion for several reasons but one of the major ones
was that nobody *should* have to hack XML with regular expressions. They
should be able to download a nice XML module and go to work on top of it
instead of pretending that the XML was just text.
So XML came around and not only did the nice modules come around for
every language but they are actually built into the distributions of
most languages now. Java is a little slow but nobody seems to have a big
problem downloading and installing parsers.
Even if XML was as hard to parse as SGML (which, thankfully, it is not)
it would be possible to make "lightweight" applications if you can
depend on using a library that someone else has written. Most
"lightweight" applications today depend on megabytes of JDK, JVM, OS,
GUI and device drivers. So "lightweight" typically means "written in a
few lines of code but built on top of mountains of it."
Part of your and my life's work has been to help develop the mountains.
As part of that exercise I claim that it should be possible to write a
single module that handles versioning for most XML applications and
transparently allows older applications to do "the right thing" with
newer documents. I claim this because I believe so strongly that XML
applications should be both lightweight AND robust and I see no reason
to require a trade-off. Build on a "version engine" and in a few lines
of code you have an application that is future-proof and tiny.
In order to invent this version engine we need a unified, implementable
concept of language versions and/or dialects. We can't just say: "HTML
is anything we say it is and an HTML dialect is anything similar."
---
Obviously there is another definition of lightweight that implies tiny
byte counts, minimal dependencies, and so forth. "Microwave oven XML"
style lightweight. But the truth is that "standard XML" and HTML are not
very good for those applications anyhow. You must design an variants
that are not so expensive to implement. Therefore I am reluctant to
start thinking about embedded processor at level 4 when levels 0 through
3 didn't really do so effectively. Microwave oven designers can develop
an XML subset (perhaps just canon XML?) and their own namespace and
versioning strategy.
I'll bet the smallest, from-scratch (i.e. using no libraries) XML
compliant parser takes up more ram than my first computer had!
Paul Prescod
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)
From paul at prescod.net Sat Sep 18 08:12:25 1999
From: paul at prescod.net (Paul Prescod)
Date: Mon Jun 7 17:15:12 2004
Subject: Another look at namespaces
References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <37E25959.6BFCE9BA@prescod.net>
Rick Jelliffe wrote:
>
> Again, Andrew is simply conflating schema and namespace. The idea that
> he and Tim are putting forward is that a language is defined by a single
> set of content models; this confuses "language" with "grammar"
What definition of language are you using that does NOT state that every
language has one and only one grammar. Is there a book I can read that
defines it? The SGML Cookbook doesn't count.
> and
> is disproved by long-standing SGML practise, in which variants of
> a language can be defined in the same DTD (selected by marked sections,
> or by simply overriding parameter entity declarations).
SGML does not (AFAIR) define the word "language." It defines the word
"document type" and a document type has one and only one grammar.
Even if we ignored this we could say that SGML use a very flexible
grammar definition language that defines grammars that are not
context-free or hedge-regular or whatever. Grammars can be
paramaterizable, extensible and otherwise complex.
But as Tim B-L and I both said, the important consideration is temporal.
XHTML 1.0 could be defined with one of these "parameterizable grammars".
We could have one dialect and neither of us would care much. But it
would set a bad precedent because it would validate this fuzzy notion of
"wink, wink, we know what a language is, nudge, nudge." This will cause
problems over time when new versions come about.
Assertion: Once there are deployed XHTML processors it should be
absolutely illegal to silently pass off new, incompatible versions as if
they were the same as old versions. New, compatible versions (e.g.
subsets) are not a problem.
A version attribute has a few problems
* it is HTML *specific* -- every document type has versioning issues
and every document type (now) has a different approach to it. There can
be no general version-handling "engine" as long as this is the case.
* the version attribute doesn't tell a new processor what it needs to
know in order to know whether it can process the document safely. Once
again, there is no standard for communicating *what has changed*.
"Rip Van Winkle, the language has changed. Certain of your grammatical
constructs have become offensive. You will be shot if you use them"
"Can you tell me which ones?"
"Sorry, you'll just have to learn by experimentation."
> If the element is removed, it is the
> declarations
> for running text that should be changed, not the declarations for .
> DTDs only provide parameter entities for this, which disguises this
> basic
> modeling truth.
The modelling language isn't the issue. The resulting grammar is the
issue. You could use prose to define XHTML -- if there are three
grammars there are three languages. If you use a flexible grammar
notation that allows the three grammars to be collapsed into one (such
as prose) then you have one language. But if we define HTML's grammar
*today* so that it automatically allows any extension we can think of in
the future:
Then we have issued an invitation for massive abuse by software vendors.
> If W3C says a namespace is a schema, they should withdraw the XML
> Namespaces
> Spec immediately.
There is a world of difference between saying that a namespace *is a
schema* and saying that there are a set of W3C specifications (including
XHTML) that have namespaces that have a one to one correspondance with
schemas. It's like saying that "p" doesn't have to be defined in a DTD
(because not every XML document has DTDs) but the *HTML* "p" *is*
defined in a DTD (which has been the stance since HTML 2).
Paul Prescod
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)
From donpark at docuverse.com Sat Sep 18 08:22:36 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun 7 17:15:12 2004
Subject: Another look at namespaces
In-Reply-To: <199909180141.BAA107642@out4.prserv.net>
Message-ID: <002b01bf019e$c40fe5e0$dceefea9@w21tp>
>Steven Pemberton, HTML WG Chair, providing the official
>rationale statement.
I don't think the official rationale statement made its appearance on the
XML-DEV yet.
BTW, please look at my "A Compromise?" thread. It discusses a possible
solution out of this mess.
Best,
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
From david at megginson.com Sat Sep 18 12:31:30 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:12 2004
Subject: Another look at namespaces
In-Reply-To: <37E257CB.75C05A3A@prescod.net>
References: <006101beffba$a2984280$a60a1712@col.w3.org>
<14304.11288.712453.705292@localhost.localdomain>
<37E257CB.75C05A3A@prescod.net>
Message-ID: <14307.27304.102083.860559@localhost.localdomain>
Paul Prescod writes:
> This sounds similar to me to a goal we set in designing XML. It's
> become corrupted over time but as I recall the original goal was
> that XML should not only be implement but "hackable" in the sense
> that you could sit down with Perl and Awk regular expressions and
> do cool things with XML documents like rename element types and so
> forth.
Yes, the famous Desperate Perl Hacker. Granted, that was a slightly
excessive goal, but in striving for it, the XML WG did create
something that was implementable. I had the first AElfred prototype
running in a couple of evenings, while I had spent over a year on and
off trying to come up with a Java-based SGML parser. The goal of
writing an XML parser in a week (i.e. 40-50 hours) is very attainable,
even by non-specialists.
I agree that there's little point in writing XML parsers any more, but
the fact that they were trivially easy to write helped massively with
their adoption -- the irony of the simplicity (or worse-is-better)
principle is that, in the end, it conceals itself: now that there is
lots of XML parsing software, it doesn't matter whether XML is simple
or complex (because the complexity is hidden from the application);
but that software wouldn't exist if XML hadn't been so simple in the
first place.
That's why, for example, we never ended up with a single Java-based
SGML parser (even though it would be just as easy to process SGML if
we did have the libraries).
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From david at megginson.com Sat Sep 18 12:48:04 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:12 2004
Subject: Another look at namespaces
In-Reply-To: <37E25959.6BFCE9BA@prescod.net>
References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU>
<37E25959.6BFCE9BA@prescod.net>
Message-ID: <14307.28278.600041.530052@localhost.localdomain>
Paul Prescod writes:
> Rick Jelliffe wrote:
> >
> > Again, Andrew is simply conflating schema and namespace. The idea that
> > he and Tim are putting forward is that a language is defined by a single
> > set of content models; this confuses "language" with "grammar"
>
> What definition of language are you using that does NOT state that every
> language has one and only one grammar. Is there a book I can read that
> defines it? The SGML Cookbook doesn't count.
Well, for natural languages, there is almost never a single grammar:
it varies (sometimes dramatically) by time, place, gender, and social
background.
The different grammars share certain patterns, which you can collect
into a meta-grammar if you wish, but that meta-grammar is necessarily
descriptive, fuzzy, and incomplete (the next field researcher in New
York City, Nairobi, or Kingston, Jamaica could find an example that
forces us to change the meta-grammar).
> > and
> > is disproved by long-standing SGML practise, in which variants of
> > a language can be defined in the same DTD (selected by marked sections,
> > or by simply overriding parameter entity declarations).
>
> SGML does not (AFAIR) define the word "language." It defines the word
> "document type" and a document type has one and only one grammar.
That's the spec, not the usage. In SGML practice, a single document
type (lower-case) is almost always defined by multiple DTDs: in other
words, the spec got it wrong, so the implementors simply worked around
it.
> But as Tim B-L and I both said, the important consideration is temporal.
> XHTML 1.0 could be defined with one of these "parameterizable grammars".
> We could have one dialect and neither of us would care much. But it
> would set a bad precedent because it would validate this fuzzy notion of
> "wink, wink, we know what a language is, nudge, nudge." This will cause
> problems over time when new versions come about.
>
> Assertion: Once there are deployed XHTML processors it should be
> absolutely illegal to silently pass off new, incompatible versions as if
> they were the same as old versions. New, compatible versions (e.g.
> subsets) are not a problem.
>
> A version attribute has a few problems
>
> * it is HTML *specific* -- every document type has versioning issues
> and every document type (now) has a different approach to it. There can
> be no general version-handling "engine" as long as this is the case.
It can become conventional for languages that need it, like the Perl
$VERSION attribute. Standards writers hate conventions (because they
didn't get to invent them), but those of us in the U.K, Canada, and
the U.S., at least, are very used to the idea that The Law is a
combination of statutes and common law.
> * the version attribute doesn't tell a new processor what it needs to
> know in order to know whether it can process the document safely. Once
> again, there is no standard for communicating *what has changed*.
Neither does the Namespace URI -- that information is available only
through outside documents (schemas, or what have you), and there is no
absolutely no difference in the mechanism for retrieving them using
the Namespace URI or the value of the version attribute.
[snip]
> The modelling language isn't the issue. The resulting grammar is the
> issue. You could use prose to define XHTML -- if there are three
> grammars there are three languages. If you use a flexible grammar
> notation that allows the three grammars to be collapsed into one (such
> as prose) then you have one language.
This is a puzzling statement -- in other words, if I use notation A to
describe it, XHTML is three languages, but as soon as I switch to
notation B, it magically becomes one? I suppose that Derrida would
approve.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From ann at webgeek.com Sat Sep 18 16:13:19 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:12 2004
Subject: Another look at namespaces
In-Reply-To: <002b01bf019e$c40fe5e0$dceefea9@w21tp>
References: <199909180141.BAA107642@out4.prserv.net>
Message-ID: <199909181415.OAA23740@out1.prserv.net>
At 11:26 PM 9/17/99 -0700, Don Park wrote:
>>Steven Pemberton, HTML WG Chair, providing the official
>>rationale statement.
>
>I don't think the official rationale statement made its appearance on the
>XML-DEV yet.
Looks like it hasn't -- perhaps because he posted as a non-subscriber.
Unfortunately, I'm on the road this weekend, and don't have my copy of it
available to repost. One or two other people, I believe, were directly cc'd
on it--perhaps they can repost it.
Otherwise, I'll do so on Monday from the office.
>BTW, please look at my "A Compromise?" thread. It discusses a possible
>solution out of this mess.
It only addresses a part of the problem, unfortunately.
Ann
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)
From simonstl at simonstl.com Sat Sep 18 16:35:14 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:12 2004
Subject: Another look at namespaces
In-Reply-To: <37E25959.6BFCE9BA@prescod.net>
References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <199909181437.KAA05856@hesketh.net>
We seem to have fallen into linguistics.
At 05:08 PM 9/17/99 +0200, Paul Prescod wrote:
>Rick Jelliffe wrote:
>>
>> Again, Andrew is simply conflating schema and namespace. The idea that
>> he and Tim are putting forward is that a language is defined by a single
>> set of content models; this confuses "language" with "grammar"
>
>What definition of language are you using that does NOT state that every
>language has one and only one grammar. Is there a book I can read that
>defines it? The SGML Cookbook doesn't count.
I could start with H.L. Mencken's _The American Language_ (Fourth Edition
with Supplements, 1948), in particular a citation of Noah Webster, in 1789:
(second supplement, p. 333)
>The most difficult task now to be be performed by the advocates
>of pure English is to restrain the influence of men learned in
>Greek and Latin, but ignorant of their own tongue, who have labored
>to reject much good English because they have not understood the
>original construction of the language.... They seem not to consider
>that grammar is formed on language, and not language on grammar.
That last sentence seems to summarize the problem we're having here.
Whether or not _The SGML Cookbook_ makes this claim that a language is not
constrained to a single grammar, I'll be making that claim in my next book,
probably giving it an entire chapter for folks who find this issue
intriguing. (Fortunately, the book isn't meant to be read straight through,
so those who find this issue boring can skip around.)
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From ricko at allette.com.au Sat Sep 18 17:38:44 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:12 2004
Subject: Unicode surrogate block in XML?
Message-ID: <006601bf01ec$c62b7670$37f96d8c@NT.JELLIFFE.COM.AU>
From: Paul W. Abrahams
>Is it really correct to refer to #x10FFFF, say, as a Unicode
>character, since Unicode characters are limited to 16 bits
If Tony wanted to be exact he would have said "Universal Character
Set character" or something similar. But then no-one would understand
what he meant!
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/ 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)
From cbullard at hiwaay.net Sat Sep 18 18:28:21 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun 7 17:15:12 2004
Subject: Another look at namespaces
References: <006801bf0068$fcdb9130$1ff96d8c@NT.JELLIFFE.COM.AU> <37E2357C.FDAD0C55@prescod.net> <37E2593B.2C01A3C@pacbell.net>
Message-ID: <37E3B94A.373@hiwaay.net>
David Brownell wrote:
>
> Perhaps a lot of the current problems with XHTML map to such issues.
> Rush one spec through with some open issues, and then watch the issues
> multiply as time goes by.
A by product of relying on a philosophy of attaining "minimum victories"
is that it can engender longer conflicts. See the history of the wars
of Rome with Carthage. On the other hand, trying for one definitive
battle can also lead to the complete destruction of both sides, or
the Pyrrhic victory. It is important at each phase of the development
of the spec to know and resolve the most important issues. Getting
it all done in one pass can also lead to a very long pass. See HyTime
and DSSSL. Both standards are as complete as one could expect for a
very complex set of requirements, some only discovered in process,
and both were so far ahead of time that we are still mining them
for building materials much as Egyptian palaces were made from
blocks and the facing materials of the pyramids at Giza.
len
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)
From cbullard at hiwaay.net Sat Sep 18 18:28:21 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun 7 17:15:13 2004
Subject: Binary-encoding of XML for communication
References: <000201bf0119$c27dd5a0$74bbfea9@w21tp>
Message-ID: <37E3B1D4.533F@hiwaay.net>
Don Park wrote:
>
> I am with TimBL on the issue with binary XML. WAP is all right but not good
> enough for general use. We need to put our heads together and squeeze one
> out. I think it should support exactly one namespace (just kidding :).
At the rate at which we are now deploying mobile communications within
both CDPD and RF systems across the world for public safety, haing no
standard
on this will be mean we will go with the most useful implementation
(probably whatever Microsoft agrees to) and that will become the de
facto
standard for one of the largest commercial applications of mobile
binaries.
Essentially, we are past the point of waiting. The RFPs are there and
vendors such as Motorola, GTE, etc. are moving on.
The problem is severe. We must be able to download and upload textual
data, mugshot images, maps, etc. in a record of authority environment.
At this time, we take a wait and see attitude toward XML because
relational systems offer ubiquitous, safe alternatives and XML appears
to be mired in its philosophical constraints.
Len Bullard
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)
From cbullard at hiwaay.net Sat Sep 18 18:28:21 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun 7 17:15:13 2004
Subject: Another look at namespaces
References: <006101beffba$a2984280$a60a1712@col.w3.org> <4.1.19990916092628.02454100@mail.webgeek.com> <37E2529D.B4A6AE83@pacbell.net>
Message-ID: <37E3B7D1.543F@hiwaay.net>
David Brownell wrote:
>
> That was the gist of Tim's point that the "definitive"
> schema would be found at the end of the namespace URI.
>
> Something can't be both optional and definitive in that
> way ... if it's optional, some other way could be be
> at least as correct/definitive.
Try a change in terminology here: record of authority. It
has a precise meaning in a contracting environment and a
contracting environment is what is required for namespaces to
be applied beyond its specification. Note that a record of
authority is that artifact by which parties are contractually
obligated, testable, and litigable.
In the process of creating documentation, only in very restricted cases
is the philosophy
of "conversation from author to reader" useful. When this philosophy
was advanced in the IETM community in the early 90s (See
Eric Jorgensen), it was in the context of a type of document
used in diagnostic systems where directive statements encoded
as dynamic node navigation was used: technical manuals and wizards.
However, there is an entirely different system of document production
and use in place to create these "conversations". When creating
documents as the record of authority for say, a system, there
will be multiple instances as the document is changed version by
version to correspond with the emerging design, the testable
product, then the product post Product Acceptance Test. At
each juncture, a unique record of authority will exist whose namespace
is or can be different. These differences may be seen as
the different names/element types that are applied within
the scope of a nested or linear set of processes. The scheduling of
processes, the binding of namespaces within these processes,
an the publication of a final record of authority for acceptance
are essential to contract based commerce. I note that commerce
is not the only application but that it is a complex case which
obviates simpler notions.
1. The Namespaces specification only assert the role of the
namespace as a means to make a string unique within a scope.
It goes no further. This does not make the spec wrong or
inadequate but it limits its role as a record of authority
in contracts to which it is applied. It also means the
silence referred to in this thread is appropriate with
regards to the spec if not to the principal authors
(separate politics and law for the sake of progress).
2. A namespace is a URI/URN. The role of the URI/URN as a
record of authority is defined by a separate specification
by the IETF (Correct?). The role is as a means to locate a
resource. The specification does not define the resource.
Correct?
3. By a third agreement, it is possible to define the nature
or use of the record of authority of a resource. Tim Bray and
others are correct in stating that this cannot in all roles
be a schema given that there are better alternatives in given
processes (eg, use of applet, schema, other programs, natural
language text, or even a registry or record that specifies any
and all of these). In effect, this is negotiable or assertable
in a record of authority.
If the namespace is to assume a role (by dint of formal specification or
local contract) as the identifier and means of locating a
record of authority, it must be useful in a dynamic process
and must be flexible with regards to the implementation of the
tools used in that process. I suggest that the concept of negotiation
(eg. MIME) is still the most effective means we have at this time
for dealing with this.
Definitiionally, HTML is the weakest case.
It is a user interface/presentation language and its
element types are only weakly associated with the semantics
of the information if tightly associated with the semantics
of presentation and navigation. Multiple namespaces in XHTML
are not efficient but they are not unexpected. Any review
of preexisting markup schemas such as MIL-M-28001 reveal that
any schema applied to a very large domain over time by multiple
contracting parties becomes very large, very cumbersome, and
very difficult to apply. Because of this, it is more likely
that the multiple namespaces as separate languages are more
tractable if for no other reason to encourage the older and
less useful languages to die off. This is a fundamental
of information ecologies.
Len Bullard
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)
From digitome at iol.ie Sat Sep 18 20:37:23 1999
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun 7 17:15:13 2004
Subject: Another try on groves
In-Reply-To: <37E1532B.82F3BB03@prescod.net>
Message-ID: <3.0.6.32.19990918192423.00ab2850@gpo.iol.ie>
[Paul Prescod]
[...]
> A frame is not an "element", it has no
>"attributes". Now I claim that a frame is an object and that it has
>properties. And any idiot knows that objects can be represented in XML
>using a variety of techniques but think about the logic of doing it this
>way: you are taking a thing that is "logically" an object, expressing it
>in terms of a text file format so that another module in the same
>process can re-interpret it as logical objects.
>
>The *only good reason* to dumb something down into XML elements and
>attributes is to move the information between processes separated by
>space, time or incompatibility.
I believe it makes perfect sense to *think* of MPEGS, PDFs,
whatever, in XML terms.
I't does not of course, make sense to *store* them as XML owing
to the enormous size bloat. But who said the XML needs to
physically exist in disk?
Case in point, I have written a SAX driver for the MySQL
relational database. I have SAX software that can happily
trundling through 1GB of records treating them as XML. The
XML never physically exists but the entire API used to
process the MySQL is SAX.
I can get programmers who have never seen MySQL, or its
API, to write MySQL processing apps using a purely
XML API. I do not see why the same cannot apply to
other formats such as graphics, sound etc. In fact,
I am working on a BMP driver right now.
> Using XML as the "universal API" is
>madness because there *is no universal API*.
I have shown above how a non-XML source (MySQL)
can be programmed with an XML API using SAX. I see
no reason why a virtual DOM could not be implemented as well.
I do not see what XML cannot be a universal API.
Reasoning that it cannot because of size restrictions
does not hold water because there is nothing stopping
an XML document being as virtual as you want it
to be. The virtual-ness of an XML document does not
stop you programming it with an XML API.
> The idea is patently
>ridiculous. (some Unix evangelists have claimed that open/read/write is
>hte universal interface but actual Unix usage demonstrates that this is
>not even close to true...look at the heavy usage of CORBA and IDL in
>Unix GUIs)
The Unix evangelists played with the idea that the concept of
*lines* of data, flowing through pipes, was the universal API.
I believe they were on the right track, but placed
too much emphasis on the concept of a "line". Joining
line-aware utilities into pipes worked brilliantly well -- for
data that fits simply into a line-oriented structure.
Things start to get bent out of shape when the data that
needs to flow between apps is hierarchical...
I believe it was the need to shunt hierarchical data around
that caused the shift to data-specific APIs. I remember writing
a C program on a Sun workstation many years ago to dump out
information about the last time a particular user had logged
on. I cannot remember what the file was called or what
the record structure was, but I do remember being suprised
that it was a lump of binary data and required its own
API. This seems very un-Unix like to me.
I do not think it is necessary to bend things out of shape
now that XML is reaching meme status. A whole new vista of
possibilities open up if you change the concept of a Unix
"pipe" from a line-oriented data flow, to an XML-oriented data
flow. Hierarchical data could then flow through pipes just
as easily as flat data. Flat data would simply be the
degenerate case of a hierarchy of depth 1. All the
advantages of pipes in terms of blocking buffers,
virtual data streams and so on remain!
I see no reason why GUI data, user logging info, whatever,
cannot be programmed with an XML API. Going the other
way towards data-specific APIs is, for me, the bad
old days of proprietary data formats, steep learning
curves and low programmer productivity.
I would love to see a Unix that could flow XML node, by node
through a pipe. Just thinking about what you could do with
it turns me into a giggling wreck:=)
regards,
Developers Day co-Chair WWW9, April 2000, Amsterdam
http://www.www9.org
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)
From paul at qub.com Sun Sep 19 02:27:20 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun 7 17:15:13 2004
Subject: W3C and 'small vendors'.
Message-ID: <00c501bf0236$4e4e3120$5df5c13f@PaulTchistopolskii>
To whom it may concern.
I hope that this letter wuld not be considered
abstract, because it is actualy an explanation
of one particular problem and suggestion for
working that problem around.
I'm not blaming the W3C, I just want to make
things better for all of us with pointing to
some particular problem. The problem
could be solved with publishing just one
paper on W3C site.
My letter is a request for paper :
"If you have no $15K and/or you have no
ability and/or need to travel across
the world, but you want to provide
a feedback to W3C you have the
following ways to participate in the
activity of W3C: ... "
I would never write this letter months before,
because at that point I was thinking that W3C
is doing realy great and the process is
reasonable and efficient ( of course, nothing
is ideal, but I saw no critical problems).
Our ( www.renderx.com)
particular experience with W3C shows that
there *is* one ( realy, I think there is just one)
problem with W3C.
The problem is: "W3C does not care about
small vendors / independend developers, and
ignoring those groups of people usualy causes
significant problems on a long run".
Those of you who are reading XSL mailing list
may know that for last months our group
( www.renderx.com)
handled a big work in the area of XSL FO WD.
We are one of top experts in that particular area,
because we simply wrote ( at the moment )
the strongest implementation of that standard.
More. We have published the "Validating DTD"
with many comments ( because such a DTD
was a show-stopper for many people, including
ourselvs and the only feedback from WG was
"we'l include it into the next WD") ( when???).
As a result some developers wrote us that
"shame on W3C - you are doing their work".
Unfortunately, so far we got no feedback from
W3C at all. I can not count a private email :
"keep posting to the XSL-list" as a reasonable
feedback on our materials, because we have
spend days and weeks preparing our materials.
I'm not concerned too much about this particular
problem ( our DTD ). Probably, with some
hidden/political steps we may establish some
kind of relations with XSL WG. Maybe not. Does
not matter.
Also, I'm *not* saying that we have something
very special with XSL FO working group. I have
some e-mails that show that the same situation
happens with almost every group in W3C. It's
easy to understand - people are bisy with their
work, there are some ( unknown ) procedures
for making the descisions, there is a
(maybe reasonable - I don't know) 'conspiracy'
angainst the outher space e t.c.
Once again - I greatly respect W3C efforts
and the efforts of XSL WG in particular. The
April draft of XSL FOs was a *great* step.
However, it is the end of September now.
The problem is that if W3C will threat us
the way it is now - it could be easier for us
to decide at some point :
"OK, we don't care about your standard stuff. We
are the only one who have the working implementation
and we'l add our own proprietary workarounds to
the problems you are ignoring for months. Well -
maybe you are not ignoring - but with zero feedback
from you and our real clients who want our engine
right now - it would be OK for us to start with
Netscape-alike 'spacer' tags e t.c. "
Again - it is not the worstest thing. The worstest thing
is that it appears that *many* small
vendors / intependend developers are having the
same problem with W3C. I got emails
from different persons and it appears that most
of people who are 'outside the W3C' are having
the similiar problems.
For years I was thinking that damn vendors who are
introducing some proprietary extensions to some
standards are doing it because of some
political / marketing reasons.
After vain attempts to get any feedback from W3C
for months, following the procedures suggested by
W3C ( posting to the XSL-list is the suggested procedure,
right? ) now I think that I was just naive and perhaps
some marginal whoes in comp.text.xml are not actualy
stupid.
I think that if it will go as it is going now with W3C
and 'ordinary people' outside, it would cause
some vendors to start with their own 'Linux' for XML
and I don't think that it will be good.
If asking me personaly:
"whould you like to start with "Linux for XML"?"
3 months ago:
My answer would be "Of course, no. It's stupid."
If asking me about the same thing today
my answer would be:
"Can I get your e-mail / url? Just in case."
It is a sad story.
If after 3 months my answer would be:
"OK, let's start a mailing list on it, we have our
part ready, you have your part ready, we need to
hack this and that place to make it work together -
let's do it right now, it'l take us forever to understand
when they will come with the next version of WD,
because they are silent for 2 months again".
It would be the worstest possible scenario for
me and W3C, because I'l start working
*aganst* W3C, but not *for* W3C. Of course just
one small case is nothing. What I'm saying is that
the *probability* of this scenario increases every day.
More and more 'ordinary people' are gaining more
expertize in XML, more and more small companies
are coming with 'some' implementations and the last
but not the least, it appears that most of W3C
memebers realy think that keeping silence
makes things better, blaming the 'rest of the world'
with : "hey, we are doing important things - don't
bother us".
After constantly receiving such answers people
like Linus usualy say:
"OK. If you don't care about me, I'l kill you with
my implementation. It's *not* a big deal to put
together a bunch of code to get my own version
of UNIX - I don't have to be a *very*big*structure*
to make some temporary descisions, because
the task itself is *not* that complex to spend
years with designing it".
The biggest problem and maybe the the only
reason of Lunix was that a *lot* of FreeBSD
developers decided that it's not worth their
time to spend their *free* efforts to support
the group of persons who are simply ignoring
them.
I don't think that at the beginning of Linux, advicing
Linus with "Just spend $15K and join our FreeBSD
team" could work.
We should learn from Linux. We are geting closer
to the same situation. There was one letter
where the man told: "Hey! Give me one million and
I'l invent the better XML". I don' think it'l work. The more
probable scenario is:
"Hey! Just give me 5-10 teams, like renderx.com
who are frustrated with W3C - constantly rejecting
them - and we'l invent the lXML ( for free, like Linux
was created). lXML will *not* conform to W3C
specs but will *work*right*now*".
It may become possible. It's not a good thing to
ignore 'ordinary people'.
Just imagine what may happen if the army of people
who were supporting Linux would join FreeBSD
community. We could definately have the best
possible Free OS.
Unfortunately we have what we have. The
reason was:
rejecting ordinary people ( like Linus ;-)
who are outside the 'elite'
I predict that if W3C would not care about
'ordinary people' like it *is* doing now it
may result in 'Linux of XML' initiative.
The descision is up to W3C.
The approach: "become an expert and everything will
be fine with you" does not work with our group.
We *are* experts in XSL FO, but we have no time for
face-to-face meetings ( however, we spend
a *lot* of time writing down our suggestions)
and it appears that we don't want to spend
$15.000.
If W3C cares about 'ordinary people' it looks
reasonable to publish some FAQ for those people.
If W3C does not care - it may be better to be prepared
for "Linux for XML" initiative.
Maybe "Linux fo XML" would not be a bad thing.
I don't know.
For me it could be better ( and it was possible )
to have a perfect Free UNIX, if not splitting efforts
and rescources between Free BSD and Linux.
BTW - many ( if not the majority ) Linux participators
came from 'non-English' world. English spelling is not
the most important thing when it comes to applications.
It *is* when it comes to writing papers. I respect both
activities greatly.
Your mileage may vary.
Rgds.Paul.
PS. My idea was not to start a discussion, because
actualy there is nothing to discuss in my letter.
I just told about my experience with W3C. I am an example
of 'ordinary person' who has not enough time for politics,
travel e t.c. because I need to write code. Actualy, this
posting appears to be my last posting to this list,
because I need to write a *lot* of code next 2 weeks.
I came to the XML world in a hope to make things better.
I tried hardly to prepare reasonable materials
( if you'l look at the comments to our DTD, you may
understand what do I mean), instead of spending too
much time on writing abstract things in mailing lists
( even I did posted some abstract things, but most
of materials were not abstract ).
Most of things have been ignored by W3C.
However, the same things were greatly
appreciated by 'ordinary people'. Also
I had a chance to compare the efficiency
of my working group with the efficiency of
W3C working group, but it is another story.
I consider our story to be the prefect
experiment with W3C and 'ordinary person' .
The experiment took more than 4 months.
I already got some understanding and it
would help me with planning my future steps.
Now I'm providing W3C with the results of my
experiment it hope that it would be useful for W3C.
It is the only purpose of my letter.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
paul@pault.com www.renderx.com www.pault.com
XMLTube * Perl/JavaConnector * PerlApplicationServer
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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)
From jtauber at jtauber.com Sun Sep 19 02:31:17 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun 7 17:15:13 2004
Subject: Signifiers/Namespaces (was Re: Another look at namespaces)
References: <03ed01bf015a$dc243cb0$a60a1712@col.w3.org><03ed01bf015a$dc243cb0$a60a1712@col.w3.org> <199909180251.WAA22043@hesketh.net>
Message-ID: <005b01bf0236$96b99ee0$0300000a@cygnus.uwa.edu.au>
> >But I didn't suggest that at all (sorry for any confusion) -- I merely
> >suggested that the Namespace-qualified name itself is just a
> >signifier. The signified is something and somewhere else. I'm fairly
> >certain that we agree on this point.
see .sig :-)
James
--
James Tauber / jtauber@jtauber.com / www.jtauber.com
Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net
Ceci n'est pas une pipe
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)
From jtauber at jtauber.com Sun Sep 19 03:22:49 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun 7 17:15:13 2004
Subject: should FOP require JDK1.2.x?
Message-ID: <011c01bf023d$c9c11c80$0300000a@cygnus.uwa.edu.au>
I'd be interested in hearing people's views on the simple question: should
FOP (my XSL formatter/renderer) require JDK1.2.x? At present it works with
1.1.x.
What are other XML developers doing? Should I stick to 1.1.x compatibility?
Or can I require 1.2.x without offending too many people?
James
--
James Tauber / jtauber@jtauber.com / www.jtauber.com
Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net
Ceci n'est pas une pipe
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)
From timbl at w3.org Sun Sep 19 04:21:07 1999
From: timbl at w3.org (Tim Berners-Lee)
Date: Mon Jun 7 17:15:13 2004
Subject: W3C's 'Moral Majesty'
Message-ID: <049001bf0246$036d3c40$a60a1712@col.w3.org>
Don Park (donpark@docuverse.com) on 11 Sep 1999 19:06:05 -0700
In http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0635.html
said:
>1. F2F and weekly telephone conferences
>Without a doubt, both forms of meetings are valuable. Faces and voices
>encourage people to work closer and reduces extremism through bonding and
>group behaviors. However, these meetings are not efficient enough to
>justify the cost of participation to individual members. If the WG member
>is an employee of a large company, then the cost is less and even enjoyable
>to certain extent. If the WG member is an independent
developer/consultant,
>the cost is high enough to prevent participation unless the member also
>happens to be the Chair.
This a crucial point: whether the cost (and the unfairness that introduces)
is worth the greater understanding and trust which builds in a face to face.
It is not a question of membership in W3C - as there is a way (as you found)
for non-members to come to meetings as invited experts - the criterion
is commitment of effort and acceptance of the charter.
This thread has had both points of the argument made closely and
I am not going to resolve it here. I understand it very well: I used myself
personally to go to IETF meetings, but I found the three week-long
international trips per year was too much, and as a result I have not
found it easy to keep track of what started life proud to be an electronic
forum for just the reasons you mention. I even notice that IESG membership
is chosen selected from physical meeting attendees, so one cannot be
part of the steering of the IETF unless one travels. (You can be on the W3C
advisory committee AC or AB without travelling. But I have to say, the
twice yearly face-face AC participation is very valuable).
When we realized a forum for all chairs would be really interesting, we
started with a face-to-face. The problems of how to run groups well
were so desperately important and fascinating and frustratingly
deep that it was a really great meeting and everyone resolved to do it
again. But when it came to find a time to do it, no one wanted to travel and
we went to phone conference from then on. There is no easy answer.
>I have been to only one WG F2F meeting and I found it painfully boring,
>tiring, and also disgusting to certain extent. Creativity is discouraged,
>progress is measured in number of easy decisions and issues raised,
>difficult decisions are deferred without exception, myriad issues are
chewed
>enthusiastically only to be spitted out and left on the floor like cheap
>gum, political complications are raised and usually dealt with sarcastic
>jokes which leaves the conflict hidden and dangerous, dinner conversations
>are laced with petty thoughts, bureaucratic whining, and blatant discussion
>of personal gains. Discussion of F2F meeting location is not based on
>reason but pleasure without regard to cost. A meeting at South of France
is
>great if your company is paying for it but not if it is coming out of your
>pocket.
(Or if you happen to be someone who does not live in the USA.
That is another form of exclusion we have to battle with.)
Yuck - that sound horrible. I hope that you didn't come to any general
conclusions about all meetings of all working
groups. I also hope that you brought this up first with the chair, in an
effort to understand and together improve the situation. If that didn't
work, I hope that you knew that the staff contact which every working group
has is there as an alternative channel.
The chairs meet regularly by teleconference and have an email list
chairs@w3.org which the general problem of "the art of consensus" (as the
member guidebook is called) are discussed. Other WG members concerned about
how the groups work are welcome. Everyone is of course trying to make the
process at once open, efficient, fair and of a high technical quality. There
is no short answer, but there is a steady flow of suggestions though from
the chairs forum (and others) via advisory board approval to the process
document and the guide.
There is also a trade-off between hoping that people will use their common
sense of social sense to be fair and work together, or whether bureaucracy
should be introduced to force them to and drive them crazy. I have seen on
this list general outcries against W3C bureaucracy, along with requests for
more administrative systems to be put in place to monitor working group
accountability.
>Telephone meetings are more efficient than F2F except there is no room for
>in-depth discussions. It is a breeding ground for hasty decisions without
>proper representation of the issues.
Well, so telephone meetings are rejected, I suppose? By the way, some
people can't afford those either unless they are called back.
Working groups are largely free to chose the form in which they will meet
simply because each working group contains a different mixture of people,
financial resources, technical complexity, social pressures, time pressure
and so on. This is not something which W3C process puts a lot of
constraints on - apart from for example forbidding going for more than 3
months at a time without publishing their results.
>2. Mailing lists
>Both WG and IG mailing lists are great but unsearchable and private.
That depends on the mailing list. The XML Signature list, for example,
is open.
>Confidentially is too broad and laced with political issues which ends up
>reducing representation of the outsiders. Issues are raised, dropped by
>inattention, and killed by time. Field of vision in mailing list
>discussions is one dimensional (even with hyperlinks) which restricts
>awareness and thus limits the level of complexity the WG can deal with.
A call for open working group lists. Maybe we should move in that direction
with new charters. If you open a group to the public, then you cut the set
of things anyone will be prepared to say. For example, an employee of a
large company will be concerned lest his personal engineering opinions be
taken by the press and used out of context to stir up scandal. As you point
out, making the group visible isn't much use unless it also responds to
input - and opening up input with no filter can drive a group into the
ground. What happens in the W3C - and needs to happen in the community - is
that a common problem is identified, that the solution fits
>All this is encouraged indirectly by W3C and its policies.
W3C is a lot of people trying to get things
right. It started with very few policies and was after a while slammed for
not having any. Those people who were concerned spent a lot of time
trying to improve it.
>If W3C can change itself, it should first relax its policy to reflect
public
>opinions more formally rather than at mercy of WG members' kindness.
Good point. Though to do something formally isn't to "relax" anything:
it means a lot of hard work. More meetings. More rules - i.e. more
bureaucracy.
> It should also install policy of independence from W3C bureaucracy.
What on earth do you mean by this? Install a policy of W3C
(the good side of people working together) being independent
of W3C (the bad side of people working together).
You are asking for more bureaucracy: rules about WG accountability
to public mailing lists. Who is going to be independent from this?
>The
>director should be stripped of his unspoken right to interfere with his
>unfairly heavy hand.
You have the shoe on the other foot, I think. It is a spoken right - nay,
written.
According to the way the original membership contracts were drawn up,
formally the Director decides what becomes a Recommendation and
what does not. In fact there is a process
http://www.w3.org/Consortium/Process
by which reviews are done, and the director as a person has very little
part.
There is also an ethos - discussed
largely by chairs and at the AC meeting - that we do not count votes,
but ideas: we do not simply override a minority opinion, but if it has
not been addressed, it is recorded and passed up a level.
At the final AC review, a comment in just one review can stop the
whole process until it has been resolved. Only occasionally have
the staff had to point out that a negative review comment was
not technically sound - normally an analysis leads to either a change
in the document or a withdrawal of the comment.
Complaints about the heavy hand of the director (HHD) or
for that matter the staff (who, no matter that they are giving up
perfectly good and much more lucrative jobs in industry to
be there and have very little reason to be arbitrary or
capricious) being unreasonable have historically occurred when
the staff have had the indeed heavy burden of ensuring that
all the bits fit together in the long run. It is all to easy to
design a wonderful and beautiful part of the machine in a working group,
and there are documents to read and write, and meetings to go to, a-plenty
without having to constantly review everyone else's work.
Here we are for example with differences about how namespaces are going
to be used. It's not just a question of designing a namespace spec, but
it being one which the other XML groups and SMIL and RDF and P3P
will find meets their expectations. This is hard work. It involves
crossing boundaries of the use of vocabulary. It involves the same person
being
aware of a lot of projects at the same time. It tends as a result to be a
full
time job.
When the full time person (a staff contact in a WG) has to try to bring
two WGs together, it may look to the WG as though that person -- a minority
in the WG -- is claiming some sort of divine priority. In fact the poor
soul is bearing all the stress between two lively groups of independent
creative thinkers.
We really need common underlying philosophy about how the future web
will work. I have joined in on this list from the technical point of view
because I was
staggered to find there seemed to be big holes in that common understanding.
On my postings I have maintained the right to state my own personal opinion.
> Second, W3C should start using and investing in
>groupware tools that allows efficient and focused online meetings,
>bookkeeping of issues and decisions so that status, factors, and
>justifications can be seen at a glance.
Oh boy, are you preaching to the choir! There is not a staff meeting which
can't be derailed into a three hour rathole by talking about tools we need
and how they should work. A breakout group in the face-face chairs
meeting worked on "Tools" and filled a flipchart with a small print list
of tools which we clearly essential. A tools group was formed but everyone
is so busy. Volunteers didn't seem to do it.
Actually, paid staff have gotten quite a way. We do have tools to
- allow HTTP 1.1 write back so minutes and issues list can be edited
directly during meeting; (Amaya/Jigsaw)
- track changes so we can take chances, get messy make mistakes - and
recover. (Jigsaw/CVS)
- diff changes, validate, check links, etc
- control access flexibly - so we can be flexible about group membership
- create new documents from templates - to save time
- bookkeeping issues: event tracking agent (ETA) This is a PHP3/mysql tool
which allows issues to be created, edited, tracked. In its early days.
- meeting registration;
- phone bridge monitoring, caller identification for faster roll call
- mailing list creation, management, audit,
- mailing list archives we are adding functionality to the open source
hypermail right now;
- the mIRC author kindly added URI tracking for us;
- and so on
Of course we have limited staff effort - meeting organization and group
coordination and running the website and stuff takes time, and there seems
an
infinite wish-list. And it is all funded from membership fees which even
those who are committing many times that amount in their own effort
seem to question.
> We must change W3C to fit the
>changing needs.
Absolutely. That is why the process provides for its own evolution.
> W3C must allow us to change it because it can not change
>itself.
If you change W3C then you add to W3C so you are W3C.
>Most of all, W3C must stop being arrogant bureacratic fools with
>grandeur self image of being THE innovative leader with THE right vision.
>To me, W3C is Tim Berners-Lee.
Thanks. I will keep both of those remarks for when my head gets too big
next. Let's face it I have this title of being The Inventor Of The Web for
some of the media and their chief concern is often why I don't want to drive
around in big cars and tell everyone what to do. Let me tell you that W3C
is not me
any more than Australia is the Queen of England. We are all innovative
leaders
and none of us have the right vision. But we all try. And you and I reserve
the
right to tear each other's vision apart.
> Tim, you must stop thinking that you have a
>monopoly on the future vision.
[BTW When you address me please include me in the To: line of the message
too!]
Actually I was pretty happy doing techy stuff and trying to build a good
process. But in the Tokyo AC meeting among other places, people stated very
clearly that one of the things they wanted was a consistent plan for the
future, a vision of where we were going, coupled with a derivation from that
of the work and relationship of the various groups - and that that was my
job.
I am philsophically very against the "One True Vision" idea and am very
happy for others to
write theirs. In fact we all refine each others ramblings into the best
consistent framework we can make at one point. I try to deliver the result
to not just the W3C
fee-investing people but anyone who can grab a web browser or a Intl. WWW
conference.
And don't think that my personal vision thing is all that is going out of
W3C.
There are plenty of examples where I would have done it differently.
Everyone knows that I think the web loses 10 points every time we solve
something using a
processing instruction -- but the community wants it that way and we have
http://www.w3.org/TR/xml-stylesheet/
I still think an RDF property would have been better but there we are.
> Instead of pushing your vision, try building
>a place where visions of others from far abroad can come together and
>interact so that the right vision can be born out of them.
That is just what I would love to do. You put it so well.
But --- do you mean come together ...by plane?
or telephone? or mailing list? From dream to reality, from concept to
deployment plan -- that is the difficult bit with social syetems as well as
technical ones.
> Be a mother, not a father.
If you mean, nurture, don't dictate, that sounds like sound advice,
though put in a rather gender linked way ;-)
Regards,
Tim Berners-Lee
> Best,Don Park - mailto:donpark@docuverse.com
>Docuverse - http://www.docuverse.com
>
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)
From jtauber at jtauber.com Sun Sep 19 04:19:06 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun 7 17:15:13 2004
Subject: Another look at namespaces
References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU> <199909181437.KAA05856@hesketh.net>
Message-ID: <016701bf0245$a632a880$0300000a@cygnus.uwa.edu.au>
Simon St.Laurent wrote:
> We seem to have fallen into linguistics.
And the problem with that is what exactly? :-)
Rick Jelliffe wrote:
> >> Again, Andrew is simply conflating schema and namespace. The idea that
> >> he and Tim are putting forward is that a language is defined by a
single
> >> set of content models; this confuses "language" with "grammar"
Paul Prescod wrote:
> >What definition of language are you using that does NOT state that every
> >language has one and only one grammar. Is there a book I can read that
> >defines it? The SGML Cookbook doesn't count.
Simon St.Laurent wrote:
> I could start with H.L. Mencken's _The American Language_ (Fourth Edition
> with Supplements, 1948), in particular a citation of Noah Webster, in
1789:
> (second supplement, p. 333)
Simon, you are talking about natural languages whereas Paul is talking about
formal languages. A formal language is a set of valid utterances. A (formal)
grammar is a collection of rules for generating that set of utterances.
Mind you, the notion of a formal grammar for a natural language is largely
due to Chomsky and you've already said you were never fond of him :-)
But that aside, XML is a formal language, not a natural one. Likewise, HTML
4.0 is (despite what anyone says) three separate (formal) languages. In the
case of HTML 4.0, the three share a common vocabulary, but they are separate
languages. Namespaces, by the REC's definition, are about
vocabularies, not languages.
[...]
> "They seem not to consider that grammar is formed on language, and not
language on grammar."
> That last sentence seems to summarize the problem we're having here.
Both "grammar" and "language" as they are used in this quote predate formal
notions by quite a few years! I think Noah Webster's point is merely that
linguistics should be descriptive, not perscriptive (first lesson in
Linguistics 101)
However, that point is misleading at best when applied to formal languages.
In particular:
* XML is a language defined by a grammar.
* The XML REC clearly says that a DTD is a grammar for a class of documents.
In a formal language view, this class of documents is a set of
utterances---a formal language.
> Whether or not _The SGML Cookbook_ makes this claim that a language is not
> constrained to a single grammar, I'll be making that claim in my next
book,
Depending on what you mean by "not constrained to" and what type of
languages you mean, I either completely agree or completely disagree with
you :-)
James
--
James Tauber / jtauber@jtauber.com / www.jtauber.com
Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net
Ceci n'est pas une pipe
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)
From whisper at accessone.com Sun Sep 19 05:50:30 1999
From: whisper at accessone.com (David LeBlanc)
Date: Mon Jun 7 17:15:13 2004
Subject: W3C's 'Moral Majesty'
In-Reply-To: <049001bf0246$036d3c40$a60a1712@col.w3.org>
Message-ID: <3.0.1.32.19990918204907.0154bd60@mail.accessone.com>
At 10:23 PM 9/18/99 -0400, Tim Berners-Lee wrote:
Having followed this thread and others of it's kind here and in various
other places, I would like to submit a modest proposal which might satisfy
all parties.
I believe that the real problem underlying the complaints aired in this
thread is that those people who are expected to promote and adapt
reccommendations issued by the W3C seem to have little voice in the
development of those reccommendations.
TB-L and others have pointed out that the participants of the WG, in many
cases, are reluctant to have their opinions etc. made public. Reasons given
are unimportant - resolving them is the issue I want to address.
As I understand it, WG's are constituted from member's employees and
non-member "invited guests or experts". It also seems that these WG's are
themselves the ones who will develop the reccommendation they are charterd
to create.
If, instead of being a development group, WG's where more of a steering
group that:
outlined the goals;
issued periodic progress notes;
issued periodic requests for comment;
published the replies to requests for comment;
organized and prduced the final reccommendation;
then I think we would all feel that we had made a contribution to
and that we had some voice/influence in it's development.
Someone is bound to point out that is precisely what WG's already do. There
are two changes I propose. Firstly, that all WG's have a requirement to
inform and consult with the interested community on a reasonably frequent
basis. The community so informed has no formal status in the WG (i.e. no
voting rights), but does have the right to comment and contribute on the
development issues and drafts on a consistant basis. Secondly to implement
this, that progress notes, requests for comment and drafts be put up on the
W3C site in the form of a wiki - an interactive document that anyone can
annotate. (Indeed, I would think that a private form of this would be a
great tool for the WG's themselves for their internal development
process(es)).
I think the formation of this sort of auxilliary to the WG's solves many
problems: the WG gets feedback from qualified interested individuals (ok
some flakes will appear too), the WG ends up with a better product from all
the additional time and expertise brought to the development; and the
interested user community has an avenue of communication and influence on
the recommendations that they will end up using.
Sorry if any or all of this is ideas that have been previously proposed,
but i'm not aware of any.
Dave LeBlanc
P.S. As long as i'm on a soapbox, how about creating a W3UG ("Wug") - The
WWW User's Group. Perhaps members are the ones who participate in the
so-called WG auxiliary. Fees (and if it is as big as one might hope, there
would need to be) would be as low as possible and based on the W3C's actual
costs in administrating membership in the group. (I would hope that annual
fees would be less then $50 and hopefully $25 or less.) - dhl
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)
From paul at qub.com Sun Sep 19 06:50:28 1999
From: paul at qub.com (Paul Tchistopolskii)
Date: Mon Jun 7 17:15:13 2004
Subject: W3C's 'Moral Majesty'
References: <3.0.1.32.19990918204907.0154bd60@mail.accessone.com>
Message-ID: <019501bf025b$295fffe0$5df5c13f@PaulTchistopolskii>
Well ... I can not resist...
I should not cut the rest of your letter, because I agree
with almost every *word*.
Even it may sound like a dream...
From: David LeBlanc
> outlined the goals;
> issued periodic progress notes;
> issued periodic requests for comment;
> published the replies to requests for comment;
If just *one* of those things would become practice,
we may get much better progress with FOs than we
have now, when W3C is assuming that it is more
efficient to drive some standard not making any
'space' for people outside the WG.
> Someone is bound to point out that is precisely what WG's
> already do.
That's simply not always true. Unfortunately.
Rgds.Paul.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
paul@pault.com www.renderx.com www.pault.com
XMLTube * Perl/JavaConnector * PerlApplicationServer
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
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)
From Jon.Bosak at eng.sun.com Sun Sep 19 07:47:04 1999
From: Jon.Bosak at eng.sun.com (Jon Bosak)
Date: Mon Jun 7 17:15:13 2004
Subject: You can't tell the players without a program
Message-ID: <199909190550.WAA00522@boethius.eng.sun.com>
For purposes of reference, here is a list of the Phase III W3C XML
Working Groups and their chairs.
Jon Bosak
Chair, W3C XML Coordination Group
========================================================================
XML Linking Working Group
Tim Bray, Textuality
Bill Smith, Sun Microsystems
W3C staff contact: Daniel Veillard
XML Schema Working Group
Dave Hollander, CommerceNet
C. M. Sperberg-McQueen, W3C
XML Query Working Group
Paul Cotton, IBM
W3C contact: Massimo Marchiori
XML Core Working Group
Paul Grosso, ArborText
David Megginson, Megginson Technologies
W3C contact: Dan Connolly
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)
From Daniel.Veillard at w3.org Sun Sep 19 13:25:18 1999
From: Daniel.Veillard at w3.org (Daniel Veillard)
Date: Mon Jun 7 17:15:14 2004
Subject: W3C and 'small vendors'.
In-Reply-To: <00c501bf0236$4e4e3120$5df5c13f@PaulTchistopolskii>
References: <00c501bf0236$4e4e3120$5df5c13f@PaulTchistopolskii>
Message-ID: <19990919072750.D32047@w3.org>
> "Hey! Just give me 5-10 teams, like renderx.com
> who are frustrated with W3C - constantly rejecting
> them - and we'l invent the lXML ( for free, like Linux
> was created). lXML will *not* conform to W3C
> specs but will *work*right*now*".
Not to be annoying, but I think there is a myth here.
If you think that rolling your own standard is in anyway similar to
the Linux approach (and hence expecting the wide acceptance it got)
you're IMHO really wrong.
Linux was successful partly because it did stick to the POSIX standard
far better than most commercial OSes. I guess there is only one
exception where Linus decided to change the behaviour from the spec
because, well it was clearly broken !
I still think that the Linux project (which I have followed quite
closely since Spring 92) is a reimplementation effort of something
which is/was a very well known problem.
On the other hand XML while building on quite some expertise coming
from SGML, HTML and related standards is rather in a definition phase,
the problem is rather creating the standard than implementing it.
We are working at a semantic and syntactic level, not purely
implementation.
Another myth is that adding code to the linux kernel can be done
by anybody, I can guarantee you that Linus is at least as selective
in deciding who he trust for taking the responsability of subparts
of the kernel code than W3C groups in selecting invited experts !
Probably far more selective actually... There is areas of the kernel
code that nearly nobody else will be able to touch.
And honnestly this very tight control is probably the best reason
why the project did stay successful. The more the area is near the kernel
or the core, the harder it is to get changes. I guess it simply
makes sense.
Anyway I wouldn't try to draw too much parallel between W3C process
and Linux developement one, they are pertaining to rather different level,
Yours,
Daniel
--
Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes | Today's Bookmarks :
Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux, WWW, rpmfind,
Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | rpm2html, XML,
http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe.
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)
From donpark at docuverse.com Sun Sep 19 16:13:04 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun 7 17:15:14 2004
Subject: W3C's 'Moral Majesty'
In-Reply-To: <049001bf0246$036d3c40$a60a1712@col.w3.org>
Message-ID: <000701bf02a9$9e07c0a0$8c1ecca1@w21tp>
Tim,
Thanks for your sincere reply. When I wrote the original message, I was
beating the drum of frustration and did not expect you to answer directly.
I applogize if you found my message too harsh; I tend to over do it
sometimes (some would say all the time).
Although I generally need two sampling to get a feel for the scale of
quality in any particular area, I think the F2F I went to was average in
quality and definitely not a horrible meeting to an average person. It was
my first so I had higher expectation than most people in the meeting. I
could tell that the Chair was working hard to make real progress and
everyone was trying to get some work done. But, with my high expectation,
inefficiency of it all loomed largely in my memory. While there is someone
to take minutes, there is a great deal of work being lost between the lines
of the minutes. There is only finite amount of time allocated for each
topic so discussions are hurried and usually scratches only the surface. My
point is that, no matter how hard one tries, such meetings are just not very
efficient by its nature.
IMHO, F2F meetings should be used only to resolve serious conflicts and to
edit the spec. Telephone meetings should likewise be used only to resolve
minor conflicts and to have straw polls. Since serious conflicts are
political in nature and not of technical nature, I have nothing against
having those minutes remain confidential. With confidential matters
isolated to F2F and telephone meetings, there should be no reason to keep
the technical discussions confidential.
Technical discussions should take place fully in public using a web-based
project management tool that keeps track of issues, tasks, schedule, people,
and resources visually over the web and allows threaded searchable
discussions. Such tools are starting to appear now in the market so it is
just a matter of deciding to use it.
While I have other complaints, I believe above changes I suggested can go a
long way in improving the W3C. If I had to sum it all up, it is this:
1. Increase public participation by separating political
and technical discussions.
2. Don't just create standards, put them into practice to
solve its own problems.
Best,
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
From ken at bitsko.slc.ut.us Sun Sep 19 17:04:15 1999
From: ken at bitsko.slc.ut.us (Ken MacLeod)
Date: Mon Jun 7 17:15:14 2004
Subject: Another try on groves
In-Reply-To: Sean Mc Grath's message of "Sat, 18 Sep 1999 19:24:23 +0100"
References: <3.0.6.32.19990918192423.00ab2850@gpo.iol.ie>
Message-ID:
Sean Mc Grath writes:
> [Paul Prescod]
> [...]
> > A frame is not an "element", it has no "attributes". Now I claim
> >that a frame is an object and that it has properties. And any idiot
> >knows that objects can be represented in XML using a variety of
> >techniques but think about the logic of doing it this way: you are
> >taking a thing that is "logically" an object, expressing it in
> >terms of a text file format so that another module in the same
> >process can re-interpret it as logical objects.
> >
> >The *only good reason* to dumb something down into XML elements and
> >attributes is to move the information between processes separated
> >by space, time or incompatibility.
>
> I believe it makes perfect sense to *think* of MPEGS, PDFs,
> whatever, in XML terms.
>
> I't does not of course, make sense to *store* them as XML owing to
> the enormous size bloat. But who said the XML needs to physically
> exist in disk?
>
> Case in point, I have written a SAX driver for the MySQL relational
> database. I have SAX software that can happily trundling through 1GB
> of records treating them as XML. The XML never physically exists but
> the entire API used to process the MySQL is SAX.
>
> I can get programmers who have never seen MySQL, or its API, to
> write MySQL processing apps using a purely XML API. I do not see why
> the same cannot apply to other formats such as graphics, sound
> etc. In fact, I am working on a BMP driver right now.
To think of data in XML terms implies a translation that is (generally
speaking) non-obvious. If it were obvious we wouldn't have so many
efforts trying to map XML to objects and vice-versa. You can make *a*
translation that is easy to use, but it won't (yet) be a general
solution. Correct me if I'm wrong, but that's probably the approach
(a [singular] translation) you used to map MySQL to SAX.
I believe many people would agree with the idea behind your point,
that a common API goes a long way to making communication and
programming tasks simpler. That's what is being suggested with the
grove paradigm: a common API can be used that provides more direct
access to the underlying data, without requiring a semantic
translation to XML first.
--
Ken MacLeod
ken@bitsko.slc.ut.us
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)
From simonstl at simonstl.com Sun Sep 19 17:40:39 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:14 2004
Subject: Another look at namespaces
In-Reply-To: <016701bf0245$a632a880$0300000a@cygnus.uwa.edu.au>
References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU>
<199909181437.KAA05856@hesketh.net>
Message-ID: <199909191543.LAA26903@hesketh.net>
At 10:20 AM 9/19/99 +0800, James Tauber wrote:
>Simon St.Laurent wrote:
>> We seem to have fallen into linguistics.
>
>And the problem with that is what exactly? :-)
In computing discussions, it usually signals that an enormous
communications breakdown either has occurred or is occurring. Alternately,
it could mean that we're on the edge of a massive breakthrough, but I don't
think that's true in this case.
>[many quotes]
>Simon St.Laurent wrote:
>> I could start with H.L. Mencken's _The American Language_ (Fourth Edition
>> with Supplements, 1948), in particular a citation of Noah Webster, in
>1789:
>> (second supplement, p. 333)
>
>Simon, you are talking about natural languages whereas Paul is talking about
>formal languages. A formal language is a set of valid utterances. A (formal)
>grammar is a collection of rules for generating that set of utterances.
I think you're both (James and Paul) overstating the distinction between
natural languages and formal languages, at least in the case of XML-derived
languages. I'm not convinced any longer that 'designing' a language makes
any sense outside of very small arenas. HTML's development has been a
mixture of design and evolution, and I don't think trying to put it back on
the Procrustean bed of design is going to help us get anywhere.
>But that aside, XML is a formal language, not a natural one. Likewise, HTML
>4.0 is (despite what anyone says) three separate (formal) languages. In the
>case of HTML 4.0, the three share a common vocabulary, but they are separate
>languages. Namespaces, by the REC's definition, are about
>vocabularies, not languages.
I think I have to suggest that there is a difference between HTML 4.0 (the
formally specified, designed-by-experts version) and HTML (the one that's
used in real life) - and do what we can to improve HTML, the real-life
version. If XHTML wants to design changes, they'd do well do consider what
the public will actually adopt, not try to force an odd notion of formal
grammars mapping to namespaces upon that public.
Of course, I already heard Tim Berners-Lee claim that "We are designing
this, not investigating it as a natural phenomenon." So maybe I shouldn't
be too hopeful in that direction.
>[...]
>> "They seem not to consider that grammar is formed on language, and not
>language on grammar."
>> That last sentence seems to summarize the problem we're having here.
>
>Both "grammar" and "language" as they are used in this quote predate formal
>notions by quite a few years! I think Noah Webster's point is merely that
>linguistics should be descriptive, not perscriptive (first lesson in
>Linguistics 101)
See above. I think you're making too strong a claim about XML vocabularies
as formal languages. I'd happily argue that they're a bunch of evolved
conventions strung together - much like natural languages, though usually
chopped down by a bunch of analysts. Where's Walter Perry when I need him?
>However, that point is misleading at best when applied to formal languages.
>In particular:
>
>* XML is a language defined by a grammar.
XML provides a foundation - much like letters give English and alphabet to
create words with. (Tim Bray: "XML is ASCII, etc.")
>* The XML REC clearly says that a DTD is a grammar for a class of documents.
>In a formal language view, this class of documents is a set of
>utterances---a formal language.
Except that in many cases there are multiple DTDs (for testing different
claims), or, in fact, no DTD at all. Without a DTD, are we truly
'grammar-less'? I don't think so.
>> Whether or not _The SGML Cookbook_ makes this claim that a language is not
>> constrained to a single grammar, I'll be making that claim in my next
>book,
>
>Depending on what you mean by "not constrained to" and what type of
>languages you mean, I either completely agree or completely disagree with
>you :-)
I guess you'll have to buy the book and find out! (Gross sales pitch, eh?)
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From simonstl at simonstl.com Sun Sep 19 18:04:24 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:14 2004
Subject: namespace for unparsed entity
Message-ID: <199909191607.MAA27697@hesketh.net>
This question deals with 'namespaces' as used by section 4 of the XML 1.0
recommendation, NOT namespaces as described by the Namespaces in XML
recommendation.
The paragraph below is from section 4 of the XML 1.0 recommendation:
>General entities are entities for use within the document content....
>Parameter entities are parsed entities for use within the DTD. These
>two types of entities use different forms of reference and are
>recognized in different contexts. Furthermore, they occupy different
>namespaces; a parameter entity and a general entity with the same name
>are two distinct entities.
This only describes the two kinds of _parsed_ entities, not the third
possibility of unparsed entities. Do unparsed entities likewise have their
own namespace? It seems like a processor could get confused if there were
unparsed and general entities with the same name, making it potentially
difficult to enforce the rules about referencing unparsed entities in
content and general entities in attributes of type ENTITY or ENTITIES.
I don't see any notes on this in the errata, so I'm hoping there's a good
simple answer.
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From boblyons at unidex.com Sun Sep 19 19:08:07 1999
From: boblyons at unidex.com (Robert C. Lyons)
Date: Mon Jun 7 17:15:14 2004
Subject: should FOP require JDK1.2.x?
Message-ID: <01BF02A0.542643C0@cc398234-a.etntwn1.nj.home.com>
James Tauber wrote:
"I'd be interested in hearing people's views on the simple question: should
FOP (my XSL formatter/renderer) require JDK1.2.x? At present it works with
1.1.x.
What are other XML developers doing? Should I stick to 1.1.x compatibility?
Or can I require 1.2.x without offending too many people?"
James,
One advantage of sticking with 1.1.x is that IE 4.0 and IE 5.0 include
Microsoft's Java VM, which supports Java 1.1.x, but not Java 1.2.x.
I suspect that many of your users have IE 4.0 or 5.0 on their PCs,
but not JDK 1.2.x.
Also, the last time I checked (several months ago), IBM's Java
virtual machine for AIX supported Java 1.1.x, but not 1.2.x.
Bob
------
Bob Lyons
EC Consultant
Unidex Inc.
1-732-975-9877
boblyons@unidex.com
http://www.unidex.com/
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)
From srn at techno.com Sun Sep 19 19:18:39 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun 7 17:15:14 2004
Subject: W3C's 'Moral Majesty'
In-Reply-To: <049001bf0246$036d3c40$a60a1712@col.w3.org> (timbl@w3.org)
References: <049001bf0246$036d3c40$a60a1712@col.w3.org>
Message-ID: <199909191719.MAA03613@bruno.techno.com>
[Tim Berners-Lee:]
> It is not a question of membership in W3C - as there is a way (as
> you found) for non-members to come to meetings as invited experts -
> the criterion is commitment of effort and acceptance of the charter.
No, these are not the governing criteria, as you of all people know
best, Tim. The actual criterion on which invitations are based is
whether or not you're invited. No number of requests to be invited,
presentations of credentials, commitments of effort, or acceptances of
a charter can overcome the problem of not being invited.
Today, the W3C process is not an open process, and it's not a system
that ordinary people can get involved in and "change from within".
The W3C process is the (rather unwieldy) tool of the dominant software
vendors, balanced against the flawed personal vision and absolute veto
power of its Director, a single human being named Tim Berners-Lee.
The institutional structure of the W3C was not designed to serve the
public interest, and even the most cursory analysis reveals that there
is little reason to expect it to create standards that are optimized
for serving the public interest. Everyone involved primarily serves
special interests, and the public is neither invited nor involved in
any meaningfully institutionalized fashion. The W3C is a software
vendor consortium; people (including W3C members) who believe
otherwise are deluding themselves. With the exception of XML 1.0
(which itself is rapidly being subverted via XML Namespaces, etc.),
W3C standards always leave room for the products of software vendors
to become indispensable to the usefulness of particular pieces of
information. The idea that the role of software is the central
organizing feature of information interchange standards is contrary to
the public interest. Software is ephemeral, while information is
eternal. Everyone owns information, while only software vendors own
software.
The idea of polluting all information with names from namespaces whose
semantics and syntactic constraints are expressed by the behavior of a
particular hunk of software is an idea that is consistent with the
welfare of software vendors. It is not consistent with the welfare of
information owners; they won't be able to buy software from the lowest
bidder. The public consists of information owners, not software
vendors.
-Steve
--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com http://www.techno.com ftp.techno.com
voice: +1 972 231 4098
fax +1 972 994 0087
pager (150 characters max): srn-page@techno.com
3615 Tanner Lane
Richardson, Texas 75082-2618 USA
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)
From ricko at allette.com.au Sun Sep 19 19:31:21 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:14 2004
Subject: Another look at namespaces
Message-ID: <001001bf02c5$1022c430$42f96d8c@NT.JELLIFFE.COM.AU>
From: Paul Prescod
>There is a world of difference between saying that a namespace *is a
>schema* and saying that there are a set of W3C specifications
(including
>XHTML) that have namespaces that have a one to one correspondance with
>schemas. It's like saying that "p" doesn't have to be defined in a DTD
>(because not every XML document has DTDs) but the *HTML* "p" *is*
>defined in a DTD (which has been the stance since HTML 2).
html:p
1) is an element for generic paragraphs (semantics);
2) is typically displayed as a block, and has sub-elements that are
typically displayed inline (presentation);
3) is under the body element of an HTML document (schematic, but
defined from descendnt to ancestor).
That defines the html:p element type pretty completely, yet no grammar
(in the sense of content models on child elements) is involved. IMHO
DTDs/content-models actually disguise or fail to express the real schema
in html:p, which is more like the three points above.
What the content model gives is a way to validate a document, and a way
to construct a document after the deep structures
(classes/archetypes/extended containment/cohesion) have been abstracted
away or ignored. That is a good enough model for a DTD, but hardly a
good enough one for naming purposes; a name should express what a thing
is, and to say that HTML has three namespaces because it has 3 DTDs is
to get tripped up on a mere artifact of the modeling capabilities of
DTDs. (And in any case, a strictly conforming XHTML document has to have
a DOCTYPE declaration, so the namespace declarations don't actually
provide any information in the document than could be found there
already.)
Why should
blah
have to use a different namespace to
blah blah
? Lets allow extensibility from the start.
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/ 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)
From Daniel.Brickley at bristol.ac.uk Sun Sep 19 20:03:27 1999
From: Daniel.Brickley at bristol.ac.uk (Dan Brickley)
Date: Mon Jun 7 17:15:14 2004
Subject: W3C's 'Moral Majesty'
In-Reply-To: <199909191719.MAA03613@bruno.techno.com>
Message-ID:
On Sun, 19 Sep 1999, Steven R. Newcomb wrote:
[sniiiippppp]
> [...] The W3C is a software vendor consortium; people (including W3C
> members) who believe otherwise are deluding themselves.
[...]
I'm sorry, I can't let this one just slip past. As Bristol University's
Advisory Committee representative to W3C, I can assure you that agendas
other than software vending are represented. Bristol University may be
many things, and there are many groups here who do produce saleable
software, but we're not software vendors. We joined W3C to participate
in the development of specifications that affect teaching, learning and
research applications in our *.ac.uk environment. And we're not alone
in this...
Dan
--
Daniel.Brickley@bristol.ac.uk
University of Bristol, Bristol BS8 1TN, UK. phone:+44(0)117-9287096
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)
From boblyons at unidex.com Sun Sep 19 20:41:41 1999
From: boblyons at unidex.com (Robert C. Lyons)
Date: Mon Jun 7 17:15:14 2004
Subject: should FOP require JDK1.2.x?
Message-ID: <01BF02AD.681DE290@cc398234-a.etntwn1.nj.home.com>
James,
I just checked IBM's site.
They now offer a preview release of Java 1.2 for AIX.
(See http://www.alphaworks.ibm.com/tech/aixforjava2.)
The other IBM Java virtual machines support 1.1.x,
but not 1.2. I found the following list at
http://www.ibm.com/java/jdk/download/index.html:
- IBM Developer Kit for Linux ?, Java (TM) Technology Edition, alphaVersion 1.1.6 (June 1999)
- IBM's port of Java 1.1.6 for AIX GA plus JIT (24 September 1998) with PTFs from 2 June 1999
- IBM's port of Java 1.1.8 for AIX Developer Release plus JIT (2 June 1999)
- IBM Developer Kit for Windows, Java Technology Edition, Version 1.1.8 GA plus JIT (30 July 1999)
- IBM's port of Java 1.1.8 for OS/390 GA plus JIT (30 July 1999)
- IBM's port of Java 1.1.8 for OS/2 Warp GA plus JIT (30 July 1999)
- IBM's port of Java 1.1.4 for VM/ESA plus NetRexx (28 August 1998)
Bob
------
Bob Lyons
EC Consultant
Unidex Inc.
1-732-975-9877
boblyons@unidex.com
http://www.unidex.com/
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)
From schen at falconwing.com Sun Sep 19 20:45:47 1999
From: schen at falconwing.com (schen@falconwing.com)
Date: Mon Jun 7 17:15:14 2004
Subject: should FOP require JDK1.2.x?
In-Reply-To: <011c01bf023d$c9c11c80$0300000a@cygnus.uwa.edu.au>
Message-ID:
Hi James, everyone,
On Sun, 19 Sep 1999, James Tauber wrote:
> I'd be interested in hearing people's views on the simple question: should
> FOP (my XSL formatter/renderer) require JDK1.2.x? At present it works with
> 1.1.x.
>
> What are other XML developers doing? Should I stick to 1.1.x compatibility?
> Or can I require 1.2.x without offending too many people?
Not all platforms have stable 1.2 support yet, in fact the only two
platforms that seem to be ok are Windows and Solaris, with Sun's JVM.
What features do you need out of 1.2 that are compelling enough to require
the move? For both Swing and the collection classes, there are unbundled
versions available for 1.1.
On the other hand, if FOP is just targetting bleeding-edge users, it would
make sense if you really need the 1.2 features.
. . . Sean.
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)
From simonstl at simonstl.com Sun Sep 19 20:58:27 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:14 2004
Subject: W3C's 'Moral Majesty'
In-Reply-To:
References: <199909191719.MAA03613@bruno.techno.com>
Message-ID: <199909191900.PAA32396@hesketh.net>
At 07:06 PM 9/19/99 +0100, Dan Brickley wrote:
>On Sun, 19 Sep 1999, Steven R. Newcomb wrote:
>> [...] The W3C is a software vendor consortium; people (including W3C
>> members) who believe otherwise are deluding themselves.
>[...]
>
>I'm sorry, I can't let this one just slip past. As Bristol University's
>Advisory Committee representative to W3C, I can assure you that agendas
>other than software vending are represented. Bristol University may be
>many things, and there are many groups here who do produce saleable
>software, but we're not software vendors. We joined W3C to participate
>in the development of specifications that affect teaching, learning and
>research applications in our *.ac.uk environment. And we're not alone
>in this...
While Dan is right - there are in fact customer organizations, even
non-profit customer organizations, with representation and participation at
the W3C - Steven's point still holds a lot of water, if not quite as much
as before.
One key area of 'consumers' that I don't see represented as W3C members is
open source software developers, which almost by definition don't have the
resources to pay the fees. (There are, admittedly, some very wealthy open
source developers - I don't count myself among them.) Even more formal
organizations like the Apache Group don't appear to be represented (last I
checked). IBM develops some open source software, even important open
source software, but I think they're something of a special case, to say
the least.
There doesn't appear to be any way to get into the W3C by sweat equity,
unless of course a group wants to invite you into the process as an invited
expert. Invited expert invitations don't have any direct connection to
sweat, however - as Steven pointed out earlier, it's a matter of being
_invited_, not of _earning_ a seat at the table.
Also, as Tim Berners-Lee pointed out, invited experts must pledge
"commitment of effort and acceptance of the charter". Acceptance of the
charter implies accepting all the secrecy that goes along with the W3C's
activities, something I wouldn't accept - and something that seems deeply
incompatible with the open participation principle underlying most open
source projects. If the 'top people' in a project can participate at the
W3C, they're still hampered from taking advantage of the full power of
their development base by the rules keeping them from sharing information
on W3C activities.
(I realize that the W3C itself operates several excellent open-source
projects. Unfortunately, this work does not seem to have had an effect on
the approach taken by the main body of W3C activities.)
The tumult and chaos of the browser wars seem to have numbed many
developers into accepting the W3C's status uncritically, but I don't know
how long that acceptance will last. Opening participation significantly
would seem to give the W3C a lot more legitimacy heading into the future,
although it would certainly increase the pressure for accountability by the
W3C.
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From simonstl at simonstl.com Sun Sep 19 20:58:20 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:15 2004
Subject: W3C and 'small vendors'.
In-Reply-To: <19990919072750.D32047@w3.org>
References: <00c501bf0236$4e4e3120$5df5c13f@PaulTchistopolskii>
<00c501bf0236$4e4e3120$5df5c13f@PaulTchistopolskii>
Message-ID: <199909191900.PAA32401@hesketh.net>
At 07:27 AM 9/19/99 -0400, Daniel Veillard wrote:
>Paul Tchistopolskii:
>> "Hey! Just give me 5-10 teams, like renderx.com
>> who are frustrated with W3C - constantly rejecting
>> them - and we'l invent the lXML ( for free, like Linux
>> was created). lXML will *not* conform to W3C
>> specs but will *work*right*now*".
>
> Not to be annoying, but I think there is a myth here.
>
>If you think that rolling your own standard is in anyway similar to
>the Linux approach (and hence expecting the wide acceptance it got)
>you're IMHO really wrong.
> Linux was successful partly because it did stick to the POSIX standard
>far better than most commercial OSes. I guess there is only one
>exception where Linus decided to change the behaviour from the spec
>because, well it was clearly broken !
I think, actually, that 'reinventing XML' wouldn't be so difficult, in part
because XML and SGML provide a similar foundation to POSIX. The problems
are relatively well understood, and evolving XML in an open fashion is
conceivable. Creating processors that use such evolution would require
commitment from developers, but perhaps the ownership that comes with
participation could spur such work, much as many of the early XML parsers
came from people who were actually involved in the development of XML 1.0.
Getting widespread support might be difficult, but there are plenty of ways
to keep an 'Open XML' within the XML tent - by creating it as a subset, for
instance, that would be interoperable. Tools like processing instructions
can be used to insure that interoperability was maintained, while allowing
'Open XML' to go its own way on issues deemed important.
I'm not sure I'm ready to support such a project, but feasibility doesn't
seem to be a problem. The trademark on XML might be more of a problem, but
Linux did find a way around that - by not calling it Unix(tm).
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From ricko at allette.com.au Sun Sep 19 21:08:28 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:15 2004
Subject: Another look at namespaces
Message-ID: <006001bf02d3$3f75c120$42f96d8c@NT.JELLIFFE.COM.AU>
From: Tim Berners-Lee
>From: Rick Jelliffe
>
>>The only information that properly belongs in a namespace is a list of
>>names.
>
>That is not useful. I realize that the word "Namespace" (as the end
result
>fo the discussions of modules or docuemnt types or vocabularies or...)
>may be an english word which does not convey this, but a
>a namespaces is a language: a set of names plus a set of syntactic
>constraints plus - to be useful - a meaning shared by writer and
recipient.
A name is useful by being available for use in a schema, document,
program, query, stylesheet or language. That use may be merely to
disambiguate
>...Making the names that populate that markup universal, so that
>vocabularies can freely be mixed, simply adds robustness to the system
in
>the face of the fact that the days of the Great Centralized
Committee-Built
>DTD In The Sky are over (good riddance). -Tim
Except for the 3 XHTMLs!
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/ 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)
From jmbolles at ThoughtWorks.com Sun Sep 19 22:15:43 1999
From: jmbolles at ThoughtWorks.com (jmbolles@ThoughtWorks.com)
Date: Mon Jun 7 17:15:15 2004
Subject: On a more pleasant note
Message-ID:
If I understand the problem correctly, this is an ideal place to use XSLT -
use pattern matching as necessary to distinguish your xml tags from html
tags, and apply templates appropriately.
Jack Bolles
Thoughtworks, LLC
PS: In the XML I'm sending out from the server, I am embedding some human
readable text encoded, obviously enough, in HTML. What would be a good way
to distinguish it from my own XML tags so that I can extract it and feed
it to the HTML renderer? Any suggestions?
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)
From ricko at allette.com.au Sun Sep 19 22:17:16 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:15 2004
Subject: W3C's 'Moral Majesty'
Message-ID: <00c201bf02dc$daf84e70$42f96d8c@NT.JELLIFFE.COM.AU>
Before I start, I should say again that I hope that we can keep this
away from sounding
like attacks on individuals. Already some W3C people apparantly think
that people
raising serious questions are "agitated" or conspiracy theorists (though
of course
GBS's aphorism along the lines that "Every profession turns into a
conspiracy against
the public" should be salutory to us all).
From: Dan Brickley
>On Sun, 19 Sep 1999, Steven R. Newcomb wrote:
>> [...] The W3C is a software vendor consortium; people (including W3C
>> members) who believe otherwise are deluding themselves.
>[...]
>
>I'm sorry, I can't let this one just slip past. As Bristol University's
>Advisory Committee representative to W3C, I can assure you that agendas
>other than software vending are represented. Bristol University may be
>many things, and there are many groups here who do produce saleable
>software, but we're not software vendors. We joined W3C to participate
>in the development of specifications that affect teaching, learning and
>research applications in our *.ac.uk environment. And we're not alone
>in this...
(My employer, Academia Sinica, has also recently joined W3C.) It is
clear from (public) member lists that non-commercial interests do not
dominate numerically or financially.
Rick Jelliffe
Not speaking privately, not on behalf of my employer.
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)
From ricko at allette.com.au Sun Sep 19 22:20:40 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:15 2004
Subject: an unfilled need
Message-ID: <00c701bf02dd$571ed690$42f96d8c@NT.JELLIFFE.COM.AU>
I note Ann Navarro's call for "An unfulfilled need" earlier this month,
on a subject I also have been calling for for 2 years+: the need for a
mechanism to bind information to names: "definitions, semantics, and
other data that may be necessary to complete their operations." This
looks to me like a case of two non-commercial voices being lost to more
important voices.
I wonder if the reason can be found in Tim B-Ls recent post:
> Rick Jelliffe:
>>There is no W3C method to declare which schema should be
>>used, akin to the stylesheet declaration.
> Yes there is: resolution of the schema URI.
Tim is saying that using the namespace URI to specify a schema
is the official W3C method. But there is nothing about this in
any W3C spec; no working group has decided this or put it out
in a public draft or spec.
On the contrary "It is not a goal that it [the namespace URI] be
directly usable for retrieval of a schema (if any exists)" says
XML NS.
That is a major architectural decision implied on top of namespaces;
the only parties I see that can benefit from hardcoding schema
URIs into namespace URIs are vendors, who could use this
mechanism and only provide schemas in languages which they
controlled or provided tools for: I don't think this is far-fetched--
Biztalk mandates XDR schemas only.
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/ 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)
From michael_champion at ameritech.net Sun Sep 19 23:10:59 1999
From: michael_champion at ameritech.net (Michael Champion)
Date: Mon Jun 7 17:15:15 2004
Subject: should FOP require JDK1.2.x?
References:
Message-ID: <004101bf02e3$aababde0$3ebdb3c7@mccdell>
----- Original Message -----
From:
To: James Tauber
Cc: XML-Dev Mailing list
Sent: Sunday, September 19, 1999 2:47 PM
Subject: Re: should FOP require JDK1.2.x?
> Not all platforms have stable 1.2 support yet, in fact the only two
> platforms that seem to be ok are Windows and Solaris, with Sun's JVM.
>
> What features do you need out of 1.2 that are compelling enough to require
> the move? For both Swing and the collection classes, there are unbundled
> versions available for 1.1.
>
> On the other hand, if FOP is just targetting bleeding-edge users, it would
> make sense if you really need the 1.2 features.
I suspect that FOP is targeting users for the forseeable FUTURE; if there is
anything
tangible in 1.2 that would make the spec cleaner and more powerful, I'd say
to
use it, even at the cost of some short-run inconvenience.
Today's bleeding edge is next year's plain old ordinary stuff, and the year
after that's
"legacy code".
Mike Champion
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)
From donpark at docuverse.com Sun Sep 19 23:39:06 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun 7 17:15:15 2004
Subject: Some notes on process: F2F & telcon & email
In-Reply-To: <3.0.32.19990919121402.00cc2620@pop.intergate.bc.ca>
Message-ID: <000001bf02e7$d9ec34a0$8c1ecca1@w21tp>
Tim,
There is no such thing as a perfectly efficient process. There is always
room for improvement and there are always more than one way to do it. If
one solution does not work, another should be tried. That is all I am
trying to do between my whining sessions. If I stayed quiet, would W3C or
TimBL have come out and answered the questions? I don't think so. Even if
suggestions for improvements come packaged in barbs, value of the content
still stands, and if W3C is wise enough to see it, it will benefit from it.
I am not saying my solution will work for W3C; it could be full of holes. I
am saying W3C should not think it has a perfectly working system.
Based on TimBL's reply, I am more hopeful than before that something good
will come out of all this. Confidentiality is a problem for the public and
a necessity for W3C. This is just a problem to be solved in my view, so I
am hacking at it. Even if a solution can not be found, we would have gained
more understanding.
As I stated in my other recent message, I believe confidentiality can be
reduced without hurting W3C by limiting them to F2F and telephone
conferences which should mainly deal with non-technical conflicts and not to
be used for technical discussions. I also believe that WG/IG mailing lists
should be replaced with web-based tools and made available to the public.
Best,
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
From schen at falconwing.com Sun Sep 19 23:41:59 1999
From: schen at falconwing.com (schen@falconwing.com)
Date: Mon Jun 7 17:15:15 2004
Subject: should FOP require JDK1.2.x?
In-Reply-To: <004101bf02e3$aababde0$3ebdb3c7@mccdell>
Message-ID:
On Sun, 19 Sep 1999, Michael Champion wrote:
I wrote:
>> Not all platforms have stable 1.2 support yet, in fact the only two
>> platforms that seem to be ok are Windows and Solaris, with Sun's JVM.
[ ... ]
>> On the other hand, if FOP is just targetting bleeding-edge users, it
>> would make sense if you really need the 1.2 features.
> I suspect that FOP is targeting users for the forseeable FUTURE; if
> there is anything tangible in 1.2 that would make the spec cleaner and
> more powerful, I'd say to use it, even at the cost of some short-run
> inconvenience.
> Today's bleeding edge is next year's plain old ordinary stuff, and the
> year after that's "legacy code".
Of course that is true, but if James is hoping for a wide array of
beta-testers and co-developers, then it doesn't make sense to move to 1.2
completely unless there is a compelling case where complicated code that
is limited by 1.1 capabilities can be reduced in a single stroke by moving
to 1.2. Many times a migration can be put off or at least 1.2-dependent
functionality can be modularized.
For example, I found it advisable to use the 1.2 Java collection classes,
but I'm fortunate in that Sun released a version of those for 1.1 users.
Swing is similar in that fashion. On the other hand, dependence
on features such as Java 2D, printing, and Media would mandate a move to
1.2.
We could make a more concrete determination if James outlined the features
he's looking to use in 1.2.
. . . Sean.
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)
From francis at redrice.com Mon Sep 20 00:13:20 1999
From: francis at redrice.com (Francis Norton)
Date: Mon Jun 7 17:15:15 2004
Subject: Another try on groves
References: <37E1532B.82F3BB03@prescod.net> <37E20A5C.75E79B93@redrice.com>
Message-ID: <37E560B1.8B0B7E12@redrice.com>
Ken MacLeod wrote:
>
> Francis Norton writes:
>
> > Now that I have some feeling for the rationale behind Groves, I'd be
> > very interested in knowing what this might mean for implementations.
> >
> > Could one come up with a language independent API like the DOM, to
> > which Grove compliant APIs would conform? Presumably there is more
> > complexity in that the DOM has a closed set of underlying object
> > types whereas each Grove interface would would have different
> > underlying object types. In Java terms, would this be an interface
> > (a totally abstract class which guarantees a core functionality in
> > any object which implements it)? Has anyone in fact built CORBA IDL
> > or a Java interface defining the Grove API, or am I coming in at the
> > wrong level?
>
> I'd like to believe you're coming in at the wrong level. Many
> languages have built-in syntax to access ``members of objects'' or
> ``fields of records'' that can often be applied to accessing
> ``properties of nodes''. In this case, the grove API is the
> language's native syntax.
>
> Where native syntax is not applicable, groves most closely resemble
> container classes (dictionaries, mappings, hash tables; lists, arrays,
> sequences). Again, a language's standard container class interface or
> protocol can be used.
>
I've gone back to my copy of Paul Prescod's short tutorial (which I can
no longer find on the 'net - does anyone have a live URL for it?) and
found in section 2.2 a case against the DOM approach of defining an API
in IDL,
"... We have found this very limiting in the Python and Perl worlds.
With these high level languages there are more convenient ways of
mapping the high level XML concepts into APIs than the ways dictated by
CORBA. ..."
So what *is* a grove implementation? For instance I think of a DOM
implementation as a program that includes or harnesses an XML parser and
provides DOM bindings for a language or protocol (such as COM). I know
that it is a DOM implementation because it follows the pre-defined DOM
API - how will I know if something is a Grove implementation?
To extend the Mozilla analogy, would a Grove-compliant world offer our
switched-on programmer (1) a language-dependent but notation-independent
API, so that her clever features could operate, at run-time, on media
that she hadn't specifically supported at build-time; or (2) would it
simply become much simpler for her to support new media at build-time,
even though each new notation would still require explicit coding to
exploit its grove features?
If (2) am I just confusing matters by talking about APIs when perhaps
the real Grove implementation effort is in defining the Grove-compliant
information set for each notation?
Francis.
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)
From Daniel.Brickley at bristol.ac.uk Mon Sep 20 00:18:28 1999
From: Daniel.Brickley at bristol.ac.uk (Dan Brickley)
Date: Mon Jun 7 17:15:15 2004
Subject: W3C's 'Moral Majesty'
In-Reply-To: <00c201bf02dc$daf84e70$42f96d8c@NT.JELLIFFE.COM.AU>
Message-ID:
On Mon, 20 Sep 1999, Rick Jelliffe wrote:
> Before I start, I should say again that I hope that we can keep this
> away from sounding
> like attacks on individuals. Already some W3C people apparantly think
> that people
> raising serious questions are "agitated" or conspiracy theorists (though
> of course
> GBS's aphorism along the lines that "Every profession turns into a
> conspiracy against
> the public" should be salutory to us all).
>
> From: Dan Brickley
>
> >On Sun, 19 Sep 1999, Steven R. Newcomb wrote:
>
> >> [...] The W3C is a software vendor consortium; people (including W3C
> >> members) who believe otherwise are deluding themselves.
> >[...]
> >
> >I'm sorry, I can't let this one just slip past. As Bristol University's
> >Advisory Committee representative to W3C, I can assure you that agendas
> >other than software vending are represented. Bristol University may be
> >many things, and there are many groups here who do produce saleable
> >software, but we're not software vendors. We joined W3C to participate
> >in the development of specifications that affect teaching, learning and
> >research applications in our *.ac.uk environment. And we're not alone
> >in this...
>
> (My employer, Academia Sinica, has also recently joined W3C.) It is
> clear from (public) member lists that non-commercial interests do not
> dominate numerically or financially.
This is true. Non-commercial organisations rarely dominate financially.
I would also be suprised for non-commercial organisations to dominate a
forum such as W3C. But that wasn't the point I was responding to.
Although vendors dominate, W3C isn't a vendor-only forum. There are a
number of us from other environments. I guess I'm just reacting against
the word 'delusional' above which seemed a little too strong.
It is expensive to put resources into any standards process. When
Bristol joined W3C, it cost us roughly the same as buying, equiping
and maintaining a PC. I think we've had a good run for our money.
While I didn't (and don't) like paying membership fees for this work,
when looking at the budgets, it's not so vastly different
from what it would cost us to participate in other activities eg.
flying off to biannual IETF meetings or whatever.
My only point here is that it is quite possible for organisations such
as ours to have a voice, and that in my experience the financial cost
of membership fees is overshadowed by the cost of having researchers'
time dedicated to working on this stuff (either in a W3C context or
simply in a research / product development context). By characterising
W3C as a vendor-only environment, this sort of involvement by other
balancing voices is discouraged. Personally I would like to see a lot
more *.ac.uk and *edu organisations play an active role in W3C work.
While the fees are_ a barrier, a bigger barrier is the self-fulfilling
notion recently circulated here that W3C is vendor-only.
Dan
--
Daniel.Brickley@bristol.ac.uk
University of Bristol, Bristol BS8 1TN, UK. phone:+44(0)117-9287096
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)
From david at megginson.com Mon Sep 20 02:04:00 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:15 2004
Subject: W3C and 'small vendors'.
In-Reply-To: <19990919072750.D32047@w3.org>
References: <00c501bf0236$4e4e3120$5df5c13f@PaulTchistopolskii>
<19990919072750.D32047@w3.org>
Message-ID: <14309.31363.477992.969459@localhost.localdomain>
Daniel Veillard writes:
> Another myth is that adding code to the linux kernel can be done
> by anybody, I can guarantee you that Linus is at least as selective
> in deciding who he trust for taking the responsability of subparts
> of the kernel code than W3C groups in selecting invited experts !
> Probably far more selective actually... There is areas of the
> kernel code that nearly nobody else will be able to touch.
>
> And honnestly this very tight control is probably the best reason
> why the project did stay successful. The more the area is near the
> kernel or the core, the harder it is to get changes. I guess it
> simply makes sense.
To balance this analogy, it's important to remember that Linus sticks
to the kernel and leaves the other layers alone (he doesn't try to
tell Richard Stallman how to run the Gnu project, for example). XML
should work that way (and the naming mechanism described by Namespace
in XML takes us partway there), but there is an annoying co-dependency
between developers -- who both expect the W3C to define everything
XML-related and blame it for trying to do too much and/or taking too
long -- and the W3C itself, who likes the attention, positive or
negative.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From david at megginson.com Mon Sep 20 02:09:41 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:15 2004
Subject: should FOP require JDK1.2.x?
In-Reply-To:
References: <011c01bf023d$c9c11c80$0300000a@cygnus.uwa.edu.au>
Message-ID: <14309.31704.125439.459475@localhost.localdomain>
schen@falconwing.com writes:
> Not all platforms have stable 1.2 support yet, in fact the only two
> platforms that seem to be ok are Windows and Solaris, with Sun's
> JVM.
JDK 1.2 behaves very well on Linux as well, at least as far as I've
pushed it over the past few months.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From bckman at ix.netcom.com Mon Sep 20 02:42:26 1999
From: bckman at ix.netcom.com (Frank Boumphrey)
Date: Mon Jun 7 17:15:15 2004
Subject: Re xml-dev Digest V1 #348
Message-ID: <001101bf0301$aba79340$19acdccf@oemcomputer>
It seems as though you seriously suggest that the lack of documentation of
the technical process of creating the spec (specifically, the issues, the
alternatives, and the rationale for the adopted solutions) is "OK" since one
can simple E-mail some WG member and ask him to explain it for you. After
all, it works so well for you!
There is usually a requirements document, followed by several public working drafts working drafts, followed by a propoaed recommendation, followed by a recommendation.
Public input is invited at every stage of this process.
At any rate, I don't have the E-mail addresses of the XHTML WG members. I
can't officially get these addresses AFAIK.
The addresses of the editors are usually on the document.
Even if I could, it would not be
practical for them to answer my questions - because they'd be swamped with
the questions of every other interested reader of the draft.
I have never failed to get a response when I've written, and the times any one has called me, I have always replied.
did somehow manage convey the rationale to all people writing to them, and I
wouldn't agree with the rationale for some specific decision, I could not go
to "another" discussion list - because there typically isn't one, or if
there is it is as full of complaints about the W3C process as this one is.
try the W3c html list.
And yes, this mailing list _is_ about "my beefs with every (XML related) W3C
spec", between other XML related things, unless someone creates a more
appropriate list for the purpose. If you are aware of one, I'd appreciate
the address.
The more this thread continues, the more I'm getting convinced there's
something wrong with the W3C.
Obviously there is a reason why proper process
documentation is not being provided. The problem is that the simplest reason
is "to hide any shady politics between member companies".
I think you've been reading too many conspiracy novels!:>)
The w3c works by consensus!,
The documentation that is not publically available is for the most part not worth reading! Many of the internal mailing lists make this list look like the embodiment of decorum and lucidity!
Another reason is
"because it would harm the quality of the resulting recommendation" -
obviously absurd, or maybe "it would slow things down too much"
It's very difficult to get 16 people to agree, yet alone a whole mailing list
Frank Boumphrey (Speaking for myself)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990920/7f691926/attachment.htm
From david-b at pacbell.net Mon Sep 20 03:02:42 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun 7 17:15:16 2004
Subject: should FOP require JDK1.2.x?
References: <011c01bf023d$c9c11c80$0300000a@cygnus.uwa.edu.au>
<14309.31704.125439.459475@localhost.localdomain>
Message-ID: <37E58835.A56E0810@pacbell.net>
David Megginson wrote:
>
> schen@falconwing.com writes:
>
> > Not all platforms have stable 1.2 support yet, in fact the only two
> > platforms that seem to be ok are Windows and Solaris, with Sun's
> > JVM.
>
> JDK 1.2 behaves very well on Linux as well, at least as far as I've
> pushed it over the past few months.
Ditto. The only thing I'd really say against JDK 1.2 is that most of
the non-licenced versions of Java (notably the GCC/GCJ one) are sticking
to the JDK 1.1 APIs for now.
Everyone's working on getting licensed versions of JDK 1.2 available
on all the other platforms. Given that they're not all there yet, I
tend to be cautious about hard-wiring in dependencies on JDK 1.2 APIs.
However, 1.2 is my primary development platform (on Linux and NT).
- Dave
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)
From nmanson at livepage.com Mon Sep 20 03:20:52 1999
From: nmanson at livepage.com (Nick Manson)
Date: Mon Jun 7 17:15:16 2004
Subject: A compromise?
In-Reply-To: <002301bf0190$d00a0820$dceefea9@w21tp>
Message-ID: <002d01bf0306$b9e87690$ea8f92d1@livepage.com>
Don,
xml:schema="-//W3C//DTD SVG July 1999//EN">
>
>
>
> Comments?
I like the mechanism and think it could be useful in other places.
One comment:
If this compromise was accepted by the W3C, I would prefer reserving
'xml:schema' for W3C xml schemas (whatever their final form) and using
'xml:doctype' for DTD files. This side-steps the issue of relying on
magic file extensions and/or proper HTTP server behaviour. Perhaps
the 'LocalPart' could be tied to mime type?
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)
From jtauber at jtauber.com Mon Sep 20 05:07:49 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun 7 17:15:16 2004
Subject: should FOP require JDK1.2.x?
References:
Message-ID: <008d01bf0315$66441e40$0300000a@cygnus.uwa.edu.au>
Thank you to everyone so far who has contributed suggestions both on the
list and directly to me. I hope people don't mind this discussion being on
the list. I figure it is of some relevance to a number of XML developers
(where *it* is the whole question of 1.2 vs 1.1, *not* the specific question
of what Fop should do :-)
> We could make a more concrete determination if James outlined the features
> he's looking to use in 1.2.
None in particular.
I have a couple of ideas though:
1. The collections framework. Although I could use that with 1.1 as a couple
of people have pointed out. My only concerns with that are:
(a) for convenience for those that don't already have collections with
1.1 it would be better for me to include it with Fop
(b) I might not be allowed to include it with Fop (I haven't checked the
licence)
(c) if I do bundle it, I would have to include a distribution of Fop
without it for those people that already have it
2. Other libraries that require 1.2. For example, some of the stuff that I'd
like to do might be nice to try out with MDSAX2 but that requires 1.2
3. Java 2D / Printing. I'd like Fop to be able to print and display on
screen directly without PDF as well as with and Java 2D / Printing would be
the obvious way to do this. The modular nature of Fop would enable me to
perhaps distribute a separate 1.2 application to do this and leave the core
as 1.1
Incidently, from 0.10.0 I've been compiling with a 1.2.2 compiler but only
using 1.1 libraries. Does anyone know if this will still cause problems for
people using 1.1. (ie should I go back to using a 1.1 compiler).
Thanks
James
--
James Tauber / jtauber@jtauber.com / www.jtauber.com
Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net
Ceci n'est pas une pipe
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)
From cbullard at hiwaay.net Mon Sep 20 05:44:31 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun 7 17:15:16 2004
Subject: W3C's 'Moral Majesty'
References: <3.0.32.19990919115750.0120e420@pop.intergate.bc.ca>
Message-ID: <37E5A8D4.36A0@hiwaay.net>
Tim Bray wrote:
>
> Making the names that populate that markup universal, so that
> vocabularies can freely be mixed, simply adds robustness to the system in
> the face of the fact that the days of the Great Centralized Committee-Built
> DTD In The Sky are over (good riddance). -Tim
Putting the technical issues that in general, working toward a universe
of freely mixable names is probably not achievable (too much domain
noise and that noise is valuable because it is the engine of evolution),
the issue at the bottom of the angst is the publication of technical
rationale
on a timely basis so that non W3C members can use the specifications
without competitive penalties.
The excellent aspect of this debate is that most of you appear to be
looking for a solution
so the community is functional.
1. Publish the rationale.
2. Use tools that make that easier.
Enjoy.
len
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)
From cbullard at hiwaay.net Mon Sep 20 05:44:36 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun 7 17:15:16 2004
Subject: W3C's 'Moral Majesty'
References: <049001bf0246$036d3c40$a60a1712@col.w3.org>
Message-ID: <37E5AD44.1A97@hiwaay.net>
It is a hard thing to be the moral authority standing between
the king and the object of his desire. No sane man wants the
job, and if by proclamation, he gets it, he would do well to
find some means to let the king have his kate and edith too.
The crux of the issue is that technical rationale for changes
to the specification should be made public. Not the discussion
itself, but the rationale. Talk to the ISO editors about how they
handle it. If I were you, I'd have a long heart to heart with
Charles Goldfarb as well. He has a rather good record for making it
work and
keeping his skin throughout. I have found him to be a deep and
very resourceful man and he has an excellent stereo.
If we are involved this deeply in a discussion of morality on
a technical list, we cannot deny the depth of the concern of
the community. We can recognize:
1. SGML made for years in face of disregard. XML has to
survive a little too much regard. That's the job. It can't
be avoided.
2. The W3C WGs can't do it all. The coalition of vendors large and
small,
multiple standards groups (IETF, ISO, MPEG etc) all have a stake and a
say.
3. It is impossible for one man to be the focus of that much firepower
for a long time. To paraphrase Byron, the sword wears out the scabard.
Any long term solution to these problems require a long term view to the
process
of specifying and getting the contracts in place which get the system
from
phase to phase. If there is a need for a vision, it is not the
technical
vision, but the vision of how these contracts will be made and
executed. It
is dry work. It is a great achievement, one for which some are
remembered
long after the current issues are forgotten.
If this discussion is to suggest a goal, Mr. Berners-Lee, perhaps it is
time
to stop, take some of the MacArthur money, go to whatever refuge,
ashram,
Mom's garden, wherever you contemplate best, and draw up that vision of
how
the W3C can work with the lists, the vendors, and the leaders of the
other
standards and specifications organizations to prepare for the time when
the W3C and the web must evolve without need of a Director. This is not
to say that you, personally, have not achieved something of worth, but
that
the best leaders eventually solve the problem of their own press.
Then, you get to go fishing and let the prarie dog farm do its thing.
len
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)
From jtauber at jtauber.com Mon Sep 20 05:59:08 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun 7 17:15:16 2004
Subject: Another look at namespaces
References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU><199909181437.KAA05856@hesketh.net> <199909191543.LAA26903@hesketh.net>
Message-ID: <009c01bf031c$a8c65100$0300000a@cygnus.uwa.edu.au>
> >> We seem to have fallen into linguistics.
> >
> >And the problem with that is what exactly? :-)
>
> In computing discussions, it usually signals that an enormous
> communications breakdown either has occurred or is occurring.
Alternately,
> it could mean that we're on the edge of a massive breakthrough, but I
don't
> think that's true in this case.
I think you meant something different by "linguistics" than what I was
thinking. I realise now you probably meant "discussions about language" and
not the actual field of study.
> I think you're both (James and Paul) overstating the distinction between
> natural languages and formal languages
All I was trying to do was point out that there is a definition of
"language", which is the one normally used by computer scientists, more
accurately called a formal language, which requires a grammar. This is the
sense of the word I think Paul meant. I think it is entirely acceptable for
him to use the term in that sense. Most introductory CS books and I would
guess almost all books on compilers and parsing would use the word
"language" in that way.
As an aside, I'm a linguist by training (with an emphasis on formal
syntactic theories) and find it refeshing to be accused of *overstating* the
distinction between natural and formal languages! :-)
[...]
> I think I have to suggest that there is a difference between HTML 4.0 (the
> formally specified, designed-by-experts version) and HTML (the one that's
> used in real life) - and do what we can to improve HTML, the real-life
> version. If XHTML wants to design changes, they'd do well do consider
what
> the public will actually adopt, not try to force an odd notion of formal
> grammars mapping to namespaces upon that public.
"Odd notion of formal grammars"? What is odd about the EBNF in XML 1.0? What
is odd about a DTD? What is odd about a DDML document? What is odd about an
XML Schema Description?
These are all called "grammars". They all define things called "languages".
They are not "grammars" and "languages" the way Noah Webster used those
words or the way you seem to use them. They are "grammars" and "languages"
the way computer scientists use those words.
Paul wasn't overstating any distinction between formal and natural
languages, he was merely using the words "grammar" and "language" in their
formal sense. Rick and you were using those terms in perhaps a different
sense. No one is more right that the other, you were just using different
senses of the words.
[...]
> I think you're making too strong a claim about XML vocabularies
> as formal languages.
Note: I never said XML *vocabularies* were formal languages. I said
(1) XML itself is a formal language (do you disagree?)
(2) DTDs define formal languages. They are grammars (do you disagree?)
I don't equate the term "XML vocabulary" with "DTD".
> >* XML is a language defined by a grammar.
>
> XML provides a foundation - much like letters give English and alphabet to
> create words with. (Tim Bray: "XML is ASCII, etc.")
I think you missed my point. All I was saying was that XML is an argument
against your contention that languages aren't defined by grammars. XML *is*
a language defined by a grammar.
> >* The XML REC clearly says that a DTD is a grammar for a class of
documents.
> >In a formal language view, this class of documents is a set of
> >utterances---a formal language.
>
> Except that in many cases there are multiple DTDs (for testing different
> claims), or, in fact, no DTD at all. Without a DTD, are we truly
> 'grammar-less'? I don't think so.
Again, I think you missed my point. DTDs are grammars (do you disagree?)
They define languages (do you disagree?) That was my point. DTDs are another
example of grammars being used to define languages.
> >> Whether or not _The SGML Cookbook_ makes this claim that a language is
not
> >> constrained to a single grammar, I'll be making that claim in my next
> >book,
> >
> >Depending on what you mean by "not constrained to" and what type of
> >languages you mean, I either completely agree or completely disagree with
> >you :-)
>
> I guess you'll have to buy the book and find out! (Gross sales pitch, eh?)
You know I plan to buy the book anyway, Simon! :-)
If by language you mean a formal language in the sense meant by computer
scientists and the L in XML, and by "not constrained to" you mean that it is
not possible, given a language, to produce a single grammar that generates
that language then I'm afraid you are wrong.
I don't actually think you mean "language" in this sense otherwise this
thread wouldn't have started.
But Paul did, and there is nothing wrong with that sense.
James
--
James Tauber / jtauber@jtauber.com / www.jtauber.com
Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net
Ceci n'est pas une pipe
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)
From david-b at pacbell.net Mon Sep 20 06:00:29 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun 7 17:15:16 2004
Subject: should FOP require JDK1.2.x?
References: <008d01bf0315$66441e40$0300000a@cygnus.uwa.edu.au>
Message-ID: <37E5B1DD.96DDE9B4@pacbell.net>
James Tauber wrote:
>
> 3. Java 2D / Printing. I'd like Fop to be able to print and display on
> screen directly without PDF as well as with and Java 2D / Printing would be
> the obvious way to do this. The modular nature of Fop would enable me to
> perhaps distribute a separate 1.2 application to do this and leave the core
> as 1.1
I certainly like the idea of direct Java2D output!
> Incidently, from 0.10.0 I've been compiling with a 1.2.2 compiler but only
> using 1.1 libraries. Does anyone know if this will still cause problems for
> people using 1.1. (ie should I go back to using a 1.1 compiler).
I'd encourage using the 1.2 compiler; there were some code generation bugs
with the 1.1 compiler that cause problems in various cases you really don't
want to have to debug.
- Dave
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)
From david-b at pacbell.net Mon Sep 20 06:18:34 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun 7 17:15:16 2004
Subject: A compromise?
References: <002301bf0190$d00a0820$dceefea9@w21tp>
Message-ID: <37E5B61B.C504A617@pacbell.net>
Don Park wrote:
>
> >I'm also curious why the HTML WG should care, since (X)HTML has
> >only DTDs (currently three of them) for which there's already
> >a standard association technique:
>
> But the current XML to DTD association mechanism has following problems:
>
> 1. Only one DTD per document
> 2. Can not specify at element granuarity
> 3. Can not replace DTD inline
I know what you're getting at, but addressing all of those is
for the future, right? An XHTML specification for today should
just use today's standards (excluding schemas) and try to avoid
creating waves (which is a problem with using three namespaces).
There's a whole range of design spaces to play with. My point
was more along the line of "schemas aren't here yet, let's not
try to design them into a standard that's supposed to ship in
the next month or so".
That said, I concur that those points you raise need addressing
in the Grand and Glorious Future World of Schemas. But I can't
see how that would fit into the notion of a near-term compromise
on how to fix the XHTML bugs ...
- Dave
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)
From murata.makoto at fujixerox.co.jp Mon Sep 20 07:35:00 1999
From: murata.makoto at fujixerox.co.jp (MURATA Makoto)
Date: Mon Jun 7 17:15:16 2004
Subject: Another look at namespaces
Message-ID: <199909200538.AA02029@archlute.fujixerox.co.jp>
Simon St.Laurent" writes:
> At 08:30 AM 9/16/99 -0700, Andrew Layman wrote:
> >[Someone] wrote that, although a schema may be somehow associated with a
> >namespace, the "meaning" of markup will be determined in a number of ways
> >such as style sheets, or procedural code, or maybe the schema. I believe
> >this understates the importance of the schema. A schema makes a
> >contribution to the Infoset.
[snip]
>
> With all due respect to Andrew Layman, I find this to be a gross
> overvaluation of schemas, and a substantial contrast with both the XML 1.0
> approach (which doesn't require validation) and with Tim Berners-Lee's
> comments, which included:
I believe that schemata should *not* contribute to the document
information at all.
An XML document without schemata or DTDs is a perfectly good citizen
in the chaotic WWW. Very often, we simply cannot make valid
documents, either because schemata or DTDs are too restrictive (or
old) or they do not exist at all. Most of the upcoming XML documents
(as opposed to XML data) on the WWW will be sometimes valid and
sometimes invalid.
Just like the semistructured database, application programs should never
rely on schemata. If they do, they would discriminate invalid documents,
which are a lot more common in the WWW. Let' use schemata only for
sanity-checking.
Makoto
Fuji Xerox Information Systems
Tel: +81-44-812-7230 Fax: +81-44-812-7231
E-mail: murata.makoto@fujixerox.co.jp
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)
From simonstl at simonstl.com Mon Sep 20 07:52:18 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:16 2004
Subject: Another look at namespaces
In-Reply-To: <009c01bf031c$a8c65100$0300000a@cygnus.uwa.edu.au>
References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU>
<199909181437.KAA05856@hesketh.net>
<199909191543.LAA26903@hesketh.net>
Message-ID: <199909200555.BAA18874@hesketh.net>
At 11:59 AM 9/20/99 +0800, James Tauber wrote:
>> I think you're both (James and Paul) overstating the distinction between
>> natural languages and formal languages
>
>All I was trying to do was point out that there is a definition of
>"language", which is the one normally used by computer scientists, more
>accurately called a formal language, which requires a grammar. This is the
>sense of the word I think Paul meant. I think it is entirely acceptable for
>him to use the term in that sense. Most introductory CS books and I would
>guess almost all books on compilers and parsing would use the word
>"language" in that way.
So we're having problems connecting the signifier 'language' to a meaning
common across the participants of this list.
>> I think I have to suggest that there is a difference between HTML 4.0 (the
>> formally specified, designed-by-experts version) and HTML (the one that's
>> used in real life) - and do what we can to improve HTML, the real-life
>> version. If XHTML wants to design changes, they'd do well do consider
>what
>> the public will actually adopt, not try to force an odd notion of formal
>> grammars mapping to namespaces upon that public.
>
>"Odd notion of formal grammars"? What is odd about the EBNF in XML 1.0? What
>is odd about a DTD? What is odd about a DDML document? What is odd about an
>XML Schema Description?
The odd notion is of "formal grammars mapping to namespaces", not of
"formal grammars", which range from useful to utterly useless. Some of
them are indeed odd, but it's not 'formal grammar' I'm questioning here.
>These are all called "grammars". They all define things called "languages".
>They are not "grammars" and "languages" the way Noah Webster used those
>words or the way you seem to use them. They are "grammars" and "languages"
>the way computer scientists use those words.
Meaning one grammar + vocabulary -> language? Where the quantities are all
one? I think in practice you may find multiple grammars used within the
same language, even a formal one, and (yuck for some) not just subsets
(once you let ANY in the door, it all goes). Trying to keep it all
exclusively singular seems to be a common dream throughout computing, but
one I hope we can leave behind more and more over time.
>Paul wasn't overstating any distinction between formal and natural
>languages, he was merely using the words "grammar" and "language" in their
>formal sense. Rick and you were using those terms in perhaps a different
>sense. No one is more right that the other, you were just using different
>senses of the words.
Well, perhaps Paul should have left Chomsky out of it...
I think we might do well to ponder whether XML is really about creating
formal languages or for encoding information already represented in natural
languages. If it's the latter, the results might be more interesting.
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From donpark at docuverse.com Mon Sep 20 08:57:51 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun 7 17:15:17 2004
Subject: A compromise?
In-Reply-To: <37E5B61B.C504A617@pacbell.net>
Message-ID: <000401bf0336$0ee6fe80$8c1ecca1@w21tp>
Nick Manson wrote:
>If this compromise was accepted by the W3C, I would prefer reserving
>'xml:schema' for W3C xml schemas (whatever their final form) and using
>'xml:doctype' for DTD files. This side-steps the issue of relying on
>magic file extensions and/or proper HTTP server behaviour. Perhaps
>the 'LocalPart' could be tied to mime type?
That should work too but the transport layer could provide the mime/type
easily enough to differentiate between XML schema and DTD. I also think
'xml:schema' should not be limited to 'the' XML Schema but all others out
there.
David Brownell wrote:
>I know what you're getting at, but addressing all of those is
>for the future, right? An XHTML specification for today should
>just use today's standards (excluding schemas) and try to avoid
>creating waves (which is a problem with using three namespaces).
Right. I made the proposal because I believe the ability to embed XHTML
fragments within arbituary XML documents without losing the ability to
validate is the key point of contention for XHTML WG. If the 'validatable
embedded XHTLM fragment' problem is solved with one namespace, we are that
much closer to putting this episode behind us.
>There's a whole range of design spaces to play with. My point
>was more along the line of "schemas aren't here yet, let's not
>try to design them into a standard that's supposed to ship in
>the next month or so".
Right again. My proposal outlines just one point of the design space. An
interesting point my proposal makes is that it is a general solution and
XHTML can use it later when and if it is adopted without having to worry
about it now. I think the whole thing started when XHTML group started
looking too far into the future. Sometimes it works, sometimes it doesn't
especially if your view is obstructed by unfinished work such as XML Schema.
>That said, I concur that those points you raise need addressing
>in the Grand and Glorious Future World of Schemas. But I can't
>see how that would fit into the notion of a near-term compromise
>on how to fix the XHTML bugs ...
Once you read the official rationale from XHTML WG, you will understand. As
always, I am jumping the gun.
Best,
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
From gdm at step-dpsl.co.uk Mon Sep 20 10:37:32 1999
From: gdm at step-dpsl.co.uk (Graham Moore)
Date: Mon Jun 7 17:15:17 2004
Subject: Groves, IsNess and the Generic Data Object. [was.. Another try on Groves]
In-Reply-To: <37E560B1.8B0B7E12@redrice.com>
Message-ID: <000201bf0343$eba1b9c0$6d01a8c0@gdm.step-dpsl.co.uk>
I have a ramble that I constructed the other day and some additional
comments about other postings.
Comments:
---------------------
************************* ---------------------------------
I saw the following from Sean
>>I believe it makes perfect sense to *think* of MPEGS, PDFs,
>> whatever, in XML terms.
This is NOT what groves are about. Groves are about thinking about the
'IsNess' of things.
XML is one thing you could get as a serialisation of a grove model.
Consider..
root node
|
----- named prop 1 - type node
|
----- named prop 2 - type basic
|
|
----- named prop 3 - type basic
|
|
----- named prop 4 - type node
|
----- named prop 5- type basic
|
|
----- named prop 6 - type basic
Above is the abstract data model for a thing. It could be any thing. There
is NO XML I have
just captured the 'IsNess' the first class properties of the thing. I have
not thought about XML I have thought about the properties of the thing.
Now, if I decided that I need a serialisation of my grove then I need
to choose a mechanism for that. Section A1.4.5 of HyTime 2nd Edition
provides us with the
canonical representation for doing such a thing.
Obviously the canonical representation is defined in terms of an SGML DTD
and thus I could
create XML and SGML instances for my grove model. Equally though I could
serialise the model as
an S-Expression.
I think the point is that the grove paradigm should not get people to think
in terms of XML
but in terms of better appreciation of the properties of the notations they
are dealing with.
I agree that the concept that groves can be seen as a way to add tags to
untaggable data as
very powerful. But the more general case is that the grove paradigm gives
names and first
classness to otherwise unaddressable properties.
---------------------
************************* ---------------------------------
Domain:
how about
www.grove-paradigm.com
In essense there is more to the grove paradigm than just the model, e.g. the
notation processor
that constructs the model, the property set defintion, the grove plan,
application conformance, suggested API's.
---------------------
************************* ---------------------------------
Ramble:
I think paul should be applauded for making groves more accesible in his
last few mails.
I wanted with this mail to re-iterate some of what Paul said and add what I
feel is the essence of the grove paradigm. In addition I wanted to present
the Generic Data Object concept and its role in the grove paradigm. I also
wanted to give some concrete explanation and focus as to the power of the
grove paradigm.
It is the concrete focus that I want to start with,
The most striking difference between XML and a Grove Model is that in the
domain of 'cars' an Grove will let you access the value of the 'door'
property, the grove for the XML representation of the car will let you
access an 'attribute' of an element that is a serialisation of the object
'door'. As Paul said, Groves remove a level of redundant indirection.
Why did I give the above example? I feel that this is such a **fundamental**
concept that it is worth exemplifying as much as possible. Secondly I need
it to lead on to the essence of of the grove paradigm and the power it
brings.
Object Oriented development is now established, we identify our entities,
they have properties and we implement them using our favourite OO langauge.
Now it happens that most peoples favourite OO lanaguge is not a dynamic
beast such as Scheme, Python or CLOS but a strongly typed langauage such as
Java or C++, there is nothing wrong with this. We construct these classes
for specific roles - see UML and the fact that classes are assigned roles
within a system. We value this as it gives us robust design, better error
handling etc etc.
Now, what if we still had some of the rigour of the typed system but one
that could be dynamic and applicable to a variety of applications. Very
nice but how does this apply to the grove paradigm.
1) When you build a grove model it adheres to a property set this is in
effect equivalent to a set of UML class definitions. So this gives us our
rigour.
2) When you build a grove model it is typically constructed in memory as an
object model. This model is constructed by a 'Notation Processor'. A
Notation processor is aware of the property set and is also aware of a
Notation or number of Notations. A Notation is a ***'thing'***. This thing
could be a Network, a Car, a Document, An application, a person, any given
data notation. Thus given a networks property set and given a network
instance a Notation processor can construct a Grove Model that allows
access to all the properties of the network as first class objects. Before
we come onto first classness and isness how can we build these heterogenous
object models. As was pointed out in a previous mail heterogeneous
collections play a big role in computing. The grove paradigm perceives that
Objects are just containers with a generic collection of key, value pairs.
The grove paradigm works at a fundamental level of computing, values
associated with names. This is achieved by having the Generic Data Object.
The GDO has closure in that it always returns a value which could be another
GDO, it is dynamic as new values can always be added. These properties
ensure that no matter what the notation is a notation processor can create
a grove model that can contain the named property values of that notation.
The Power of Groves....
The value of OO is in having something, an entity, that is malable,
touchable, something that can be manipulated. Many systems are not
empowered as they do not have their assets, their properties as first class
objects. The grove paradigm provides the ability to make everything first
class. e.g. the thread on the bolt on the door of a car becomes a node - a
malable object - within the grove paradigm.
Now, in the world of groves we only ever have nodes and properties thus if
we have 1000 notations that have notation processors for them then we have
a abstract data model for *all* these notations. We can interchange these
nodes at the abstract level, we can link bewteen nodes at an abstract level
without needing to know about the details of the underlying notation. I can
link from my thread on the bolt on the car to the procedure of screwing on
the nut in a technical manual. Note - that the thread on the bolt IS the
thread on the bolt not a *document* about the thread on the bolt.
Why the confusion with Groves and XML
It appears that the dynamism and extensibility of XML and Groves provides a
good match. The thing to remember is that the Property set for every XML
document is the same. I never have the property 'colour' on a grove node for
an XML document I only ever have 'attribute', 'name', 'value', 'gi'
e.g. given this XML doc
I can only say if I have a grove of the XML doc
print node.attribute.name
colur
print node.attribute.value
red
Now, if I have a grove that represents the object car
I can say
print node.colour
red
The general grove model provide *IsNess* you talk about the thing as it IS,
you talk about something in terms of the properties that help form its
instance identity [identity obviously exists beyond the properties and their
value]. The IsNess of an XML document is about attributes, elements and
their values. The IsNess of a car is parts, colour, engine power etc.
Summary
The grove model enables a level abstract playing field in which to bring all
notations - things. This is possible through the use of Generic Data
Objects and their inherent dynamism and closure property. The grove paradigm
helps us understand the essence of a notation so that we may manipulate
*any* aspect of it.
Kind Regards,
Graham.
*------------------------------------------
* Graham Moore
* Consultant STEP-DPSL
* gdm@step-dpsl.co.uk
*------------------------------------------
________________________________________________________________________________
This message has been checked for all known viruses by the Star Screening System
http://academy.star.co.uk/public/virustats.htm
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)
From jtauber at jtauber.com Mon Sep 20 10:46:08 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun 7 17:15:17 2004
Subject: Another look at namespaces
References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU><199909181437.KAA05856@hesketh.net><199909191543.LAA26903@hesketh.net> <199909200555.BAA18874@hesketh.net>
Message-ID: <001d01bf0344$a8740b20$0300000a@cygnus.uwa.edu.au>
> So we're having problems connecting the signifier 'language' to a meaning
> common across the participants of this list.
Indeed :-)
> The odd notion is of "formal grammars mapping to namespaces", not of
> "formal grammars", which range from useful to utterly useless. Some of
> them are indeed odd, but it's not 'formal grammar' I'm questioning here.
Oh good.
> >These are all called "grammars". They all define things called
"languages".
> >They are not "grammars" and "languages" the way Noah Webster used those
> >words or the way you seem to use them. They are "grammars" and
"languages"
> >the way computer scientists use those words.
>
> Meaning one grammar + vocabulary -> language? Where the quantities are all
> one?
You don't actually need the "vocabulary". The alphabet of a formal language
is part of the grammar.
> I think in practice you may find multiple grammars used within the
> same language, even a formal one
Ahh. But now you are using "language" in a way other than "the set of
utterances generated by the grammar" right? Unless you mean that sometimes
the same syntactic rules can be expressed two different ways eg
a+
versus
a a*
> and (yuck for some) not just subsets (once you let ANY in the door, it all
goes). Trying to keep it all
> exclusively singular seems to be a common dream throughout computing, but
> one I hope we can leave behind more and more over time.
Let me stress again, I am not saying you can always have a single grammar
for a particular "language". I am saying that you can have a single grammar
for a particular "formal language in the sense used by Paul".
> I think we might do well to ponder whether XML is really about creating
> formal languages or for encoding information already represented in
natural
> languages. If it's the latter, the results might be more interesting.
Why can't it be both? Isn't that the whole point of write schemata
(including DTDs)? Isn't it about formalising the encoding of this
information.
James
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)
From mtbryan at sgml.u-net.com Mon Sep 20 10:50:05 1999
From: mtbryan at sgml.u-net.com (Martin Bryan)
Date: Mon Jun 7 17:15:17 2004
Subject: an unfilled need
Message-ID: <00fd01bf0345$73f62080$97c566c3@unet.com>
Rick Jeliffe wrote
> I note Ann Navarro's call for "An unfulfilled need" earlier this month,
on a subject I also have been calling for for 2 years+: the need for a
mechanism to bind information to names: "definitions, semantics, and
other data that may be necessary to complete their operations." This
looks to me like a case of two non-commercial voices being lost to more
important voices.
This view has also been expressed by The XML/EDI Group, and the recently
formed CEN/ISSS Defining and Managing Semantics and Datatypes project team,
but in this case they have been discussing them in terms of the semantics of
electronic commerce.
>I wonder if the reason can be found in Tim B-Ls recent post:
> Rick Jelliffe:
>>There is no W3C method to declare which schema should be
>>used, akin to the stylesheet declaration.
> Yes there is: resolution of the schema URI.
>Tim is saying that using the namespace URI to specify a schema
is the official W3C method. But there is nothing about this in
any W3C spec; no working group has decided this or put it out
in a public draft or spec.
>On the contrary "It is not a goal that it [the namespace URI] be
directly usable for retrieval of a schema (if any exists)" says
XML NS.
>That is a major architectural decision implied on top of namespaces;
the only parties I see that can benefit from hardcoding schema
URIs into namespace URIs are vendors, who could use this
mechanism and only provide schemas in languages which they
controlled or provided tools for: I don't think this is far-fetched--
Biztalk mandates XDR schemas only.
One of the techniques the XML/EDI community have been propounding is the use
of namespaced attributes to point to semantic specifications using the XLink
mechanism or an application specific mechanism. Basically the namespace of
the attribute points to the rules for interpreting the attribute value and
the value of the attribute points to the definition of the semantics that
are to be applied to the element. This way you do not need to rely on the
namespacing of the element name - you simply indirect your element name into
the name space of the semantics definer. Using this technique you can
decouple the model language used for the message from any model associated
with the semantics. This means that it does not matter how the semantics
have been defined (XML-Data, RDF, text, etc) you can still use a DTD or a
Schema to model your message. To me this gets over the problems that would
arise if W3C tried to define formal mechanisms for the linking of namespace
URIs to schemas, etc.
Martin Bryan
Warning: As I only have time to look at the weekly XML-DEV archive, and will
be out of the country for the rest of this week, I may not reply in a timely
function to any reactions to this message.
-----------------------------------------------------------------
Martin Bryan, 29 Oldbury Orchard, Churchdown, Glos GL3 2PU, UK
Phone/Fax: +44 1452 714029 E-mail: mtbryan@sgml.u-net.com
For more information about The SGML Centre contact
http://www.sgml.u-net.com
For more information about the European Commission's
Open Information Interchange (OII) initiative contact
http://www.echo.lu/oii/en/oiistand.html
For more information about the ISIS XML/EDI Project contact
http://wwe.tieke.fi/isis-xmedil.html
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)
From ricko at allette.com.au Mon Sep 20 12:05:07 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:17 2004
Subject: Another look at namespaces
Message-ID: <009f01bf0350$92a66a70$41f96d8c@NT.JELLIFFE.COM.AU>
From: Paul Prescod
>Rick Jelliffe wrote:
>>
>> Again, Andrew is simply conflating schema and namespace. The idea
that
>> he and Tim are putting forward is that a language is defined by a
single
>> set of content models; this confuses "language" with "grammar"
>
>What definition of language are you using that does NOT state that
every
>language has one and only one grammar.
The distinction between language and grammar is one of common
English usage (refer to any dictionary) and does not need justification.
To fixate on that subsiduary phrase is to ignore my point.
My meaning would have been clearer if I said:
>> The idea that he and Tim are putting forward is that a (markup)
>> language is (completely or primarily or fundamentally) defined
>> (as distinct from partially described) by a single set of content
>> models; this confuses "language" (as common used) with
>> "grammar" (as commonly used).
My evidence for this was that they said that because HTML 4 has
three DTDs, it should have three namespaces.
Only the superficial aspects of a markup language (i.e., its syntax)
can be defined with a content model. Its semantics cannot.
I could have the same content models as HTML but with completely
different semantics; they are not the same language (as commonly
used), even though they may have the same grammar (as commonly
used). (This distinction, that the Document Type Definition is not
the same as the markup declarations, is as old as SGML. I have never
heard anyone claim that markup languages are pure syntax with no
semantics (where "semantics" is used not in the sense of in opppsition
to "structure" or "denotation" but in the sense of in opposition to
"syntax".)
(Actually, Tim BL has clarified that he can go along with the idea that
content models "describe" rather than "define" a language.)
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/ 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)
From ricko at allette.com.au Mon Sep 20 12:08:43 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:17 2004
Subject: an unfilled need
Message-ID: <00a201bf0351$035268f0$41f96d8c@NT.JELLIFFE.COM.AU>
From: Martin Bryan
>... Using this technique you can
>decouple the model language used for the message from any model
associated
>with the semantics. This means that it does not matter how the
semantics
>have been defined (XML-Data, RDF, text, etc) you can still use a DTD or
a
>Schema to model your message. To me this gets over the problems that
would
>arise if W3C tried to define formal mechanisms for the linking of
namespace
>URIs to schemas, etc.
To find the schema applicable for a namespace, we should not have
a function:
fetch-resource(namespace-URI)
Instead, there it should go through some service:
get-resource(namespace-URI, namespace-resolver-service-URI,
preferred-syntax, resource-type)
where resource-type could be "syntactic-schema", "semantic-schema",
"documentation", etc.
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/ 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)
From digitome at iol.ie Mon Sep 20 12:13:31 1999
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun 7 17:15:17 2004
Subject: Groves, IsNess and the Generic Data Object. [was.. Another
try on Groves]
In-Reply-To: <000201bf0343$eba1b9c0$6d01a8c0@gdm.step-dpsl.co.uk>
References: <37E560B1.8B0B7E12@redrice.com>
Message-ID: <3.0.6.32.19990920110001.00977330@gpo.iol.ie>
Graham,
Thanks for this post. I think this is a useful
discussion...
[Graham Moore]
>I saw the following from Sean
>
>>>I believe it makes perfect sense to *think* of MPEGS, PDFs,
>>> whatever, in XML terms.
>
>This is NOT what groves are about. Groves are about thinking about the
>'IsNess' of things.
>
>XML is one thing you could get as a serialisation of a grove model.
>
>Consider..
>
>root node
>|
>----- named prop 1 - type node
> |
> ----- named prop 2 - type basic
> |
> |
> ----- named prop 3 - type basic
>|
>|
>----- named prop 4 - type node
> |
> ----- named prop 5- type basic
> |
> |
> ----- named prop 6 - type basic
>
>
>Above is the abstract data model for a thing. It could be any thing. There
>is NO XML I have
>just captured the 'IsNess' the first class properties of the thing. I have
>not thought about XML I have thought about the properties of the thing.
In the above you have done what any intelligent, carbon based
life form known to man would have done -- you have structured
a domain model into a *hierarchy* of objects. I look at
your diagram and in my head I see nodes called "named prop 1"
and "named prop 4". I see other nodes that are contained
within these nodes called "named prop 2" and so on.
That level of abstraction -- nodes -- is all I need to
process this data -- given some simple API. XML
provides such a simple API. I need to simply
mentally map the nodes and arcs into XML
terminology of elements and attributes. This
done, I can write software apace
using SAX, DOM or any other XML API.
Lets pretend the above data is in a data format
known as FOO and accessible in CORBA land via
a FOO-API. You seem to be asserting
that I need a "grove" for this because the
property set mechanism of the grove paradigm
allows me to work in terms of an object
API rather than an XML API. In other
words this:
# Access instance variable "named prop 5"
# of object "named prop 4"
named prop 4.named prop 5
instead of this:
(or its equivalent (ontological arguments aside))
...
I don't buy it. I personally do not find the prospect of
programming the latter rather than the former in any way
daunting or limiting. It is a trivial transformation to
take a hierarchy of typed nodes and associated attributes
and create an object hierarchy if I really want to be able
to use "object.instance attribute" syntax.
>
>Now, if I decided that I need a serialisation of my grove then I need
>to choose a mechanism for that. Section A1.4.5 of HyTime 2nd Edition
>provides us with the
>canonical representation for doing such a thing.
>
>Obviously the canonical representation is defined in terms of an SGML DTD
>and thus I could
>create XML and SGML instances for my grove model. Equally though I could
>serialise the model as
>an S-Expression.
>
Agreed.
>I think the point is that the grove paradigm should not get people to think
>in terms of XML
>but in terms of better appreciation of the properties of the notations they
>are dealing with.
This is where I think you have misunderstood my position. As human
beings we have a cognitive pre-disposition to thinking in terms
of hierarchies. There are many, many ways to represent such
hierarchies syntactically - C++ programs, SGML, S-Expressions,
tortuously inter-linked relational database tables, CODASYL,
STEP and of course XML.
They are all basically syntactic sugar. The hierarchy exists
independently of any syntactic form used to give it a digital
rather than cognitive form. XML has a nice simple syntactic
representation for hierarchies. It uses certainly terminology
to do that - elements and attributes. This terminology leads
naturally to an API for hierarchies that uses terms like:
startElement
attributeList
and so on.
This API is all you need to process arbitrary hierachies
of data. It is *not* a pre-condition of programming
to this API that the data must have been previously
serialized in XML notation!
Earlier in talking about "IsNess" you say:
>There is NO XML
This is exactly my point! XML is syntax for representing
a hierarchy. This syntax leads naturally to an API
that is couched in terms of elements/attributes. This
API is the key. You do not *need* to serialize data
to XML syntax in order to use this API.
>
>I agree that the concept that groves can be seen as a way to add tags to
>untaggable data as
>very powerful. But the more general case is that the grove paradigm gives
>names and first
>classness to otherwise unaddressable properties.
>
I see it as a trivial transformation to convert a
hierarcy of elements and attributes into a
collection of objects with associated instance
variables.
I believe this has been done on
numerous occasions in the SGML world. I think
it was Bob duCharme who wrote a paper about
transforming SGML instances into object hierarcies
using Smalltalk as the implementation language.
Some time ago, I prototyped an algorithm to do it
in Python but I never got around to implementing
it because I never saw the benefit of it for
my work. Having said that, I do not work with
STEP or CAD system data where I guess such
a model transformation would be more useful.
[...]
>It is the concrete focus that I want to start with,
>
>The most striking difference between XML and a Grove Model is that in the
>domain of 'cars' an Grove will let you access the value of the 'door'
>property, the grove for the XML representation of the car will let you
>access an 'attribute' of an element that is a serialisation of the object
>'door'. As Paul said, Groves remove a level of redundant indirection.
But this transformation is trivial! I guess I am having
difficult seeing why I need to employ the vast edifice
of abstraction that is the "grove paradigm" in order
to do this.
Somewhere along the line someone seems to have had
an "Aha!" moment which went like this
"...ergo we need groves".
It is the "..." bit that I do not see.
regards,
Developers Day co-Chair WWW9, April 2000, Amsterdam
http://www.www9.org
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)
From philipnye at freenet.co.uk Mon Sep 20 13:13:03 1999
From: philipnye at freenet.co.uk (Philip Nye)
Date: Mon Jun 7 17:15:17 2004
Subject: Another try on Groves
References: <000201bf0343$eba1b9c0$6d01a8c0@gdm.step-dpsl.co.uk>
Message-ID: <37E619C3.50DB364A@freenet.co.uk>
Graham Moore wrote:
> I can
> link from my thread on the bolt on the car to the procedure of screwing on
> the nut in a technical manual. Note - that the thread on the bolt IS the
> thread on the bolt not a *document* about the thread on the bolt.
This is where I get lost - my Unbrako catalogue does not make any
mention of links when I buy a box of M5 screws. I've just got the box
out and checked and try as I might I cannot get the screw to do anything
remotely resembling following a link. I cannot even find such a link in
a car stuffed full of microprocessors. Is this because General Motors
and Unbrako haven't bought into the Grove paradigm?
Or do you mean that the grove takes you from some internal (computer)
model of the thread to a (computer) model of the procedure for screwing
without an intermediate document format?
What I have still failed to grasp about groves, is what is missing? Why
aren't we all using them?
By this I mean, what work needs to be done in the real world to start
the ball rolling. Does some enabling code need to be written (parser,
compiler, class definition or whatever)? Does a notation need to be
developed and formalised? Does an ISO, ANSI, IEC, IETF, W3C or whatever
task force need to be appointed to make it happen? Or do we all simply
need to think groves while designing whatever we were going to design
anyway?
I have a real application now where I am puzzling over the best way to
express links between objects which sit very well in a hierarchical
tree. Some of these objects are XML documents, while some are properties
of other devices. Where should I start applying groves to this problem
if at all?
Philip Nye
Engineering Arts UK
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)
From ricko at allette.com.au Mon Sep 20 13:12:45 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:17 2004
Subject: Another look at namespaces
Message-ID: <00c901bf0359$f186cfe0$41f96d8c@NT.JELLIFFE.COM.AU>
From: James Tauber
Simon St.Laurent wrote:
>> Whether or not _The SGML Cookbook_ makes this claim that a
>> language is not constrained to a single grammar, I'll be making
>> that claim in my next book,
>
>Depending on what you mean by "not constrained to" and what type of
>languages you mean, I either completely agree or completely disagree
with
>you :-)
My book, "The XML & SGML Cookbook", which is the only book in
print AFAIR on the subjects of markup schemas in general (Eve Maler's
book is a methodology of creating DTDs and also contains much in
this regard, Dave Megginson's book looks at specific DTDs and similarly
has much thought on these issues).
I am looking forward to Simon's book too, and I am sure that many
new ideas will come out of the XML Schema development effort. If
other authors have books on schemas in general (i.e., not the syntax)
then I am sure that the XML-DEV readers will appreciate a
notification of its existence.
My book has nothing on the subject of formal language theory, though
it certainly mentions that architectural forms allow parallel content
models which work together to describe the syntax of a language. (I.e.,
we could say
that a document satisfies a language if it is both valid against the
direct
DTD and valid when validated against the architecture.) This is a clear
example of a language requiring more than one content model.
I think Paul's original comment mentioning my book is because IMHO
markup languages and DTDs are not currently about data modeling
but instead are concerned with software engineering. So in my chapter
on this I mention that Yourdan and Constantine's ideas of "cohesion
and coupling" of software modules also applies well to DTDs, to guide
when to make elements sub-elements or siblings. (People who need
XML to be concerned with data-modeling will naturally be confised
when to use an attribute or element, etc.)
So in another post I took this cohesion/coupling idea one step further
to say that schema languages should be modeling these cohesion/coupling
relationships; superficial grammars such as content models hide these,
no matter how much we valiantly use PEs to document them.
The example I gave was the html:p element. IMHO defining and
namespace-naming the html:p element in terms of its content model
elevates the content model to an importance in describing the actual
schema of HTML too much. An html:p element is a block element
found in the body element of an HTML document whereever general
block elements can be placed, and it can contain mixed content, with
any of the inline elements that are found in mixed content underneath
the body element. That is the deeper syntax for html:p, as far as I
can see.
Now you could model this using a grammar by introducing
productions to name content models:
html:p ::= ( $generic-text-elements )*
$generic-text-elements ::= #PCDATA | html:em | html:a |...
This reflects the deeper structure better. Also, it makes it clear
that a change in generic-text-elements does not bubble up to
require some change in our understanding of html:p.
The html:p element type is highly cohesive to the html:body
element and to general-inline-text element types. But the
general-inline-text
element types are not highly cohesive to paragraphs: they can also
appear
in many other elements. There is an asymmetry to the cohesion that
reveals that there is an intermediate layer; a schema describes
couplings
not cohesion, but it is good software engineering practise to only
couple
highly cohesive modules. Otherwise you over or under-specify the
structure. An appropriate schema language allows fine-enough grained
coupling of highly cohesive modules (element types, here): for example,
the use EBNF by RDF.
To go back to my orignal statement that Paul was responding to:
it disputed "the idea..that a language is defined by a single set of
content models". Paul just wanted me to avoid repeating the
cohesion/coupling line and try to explain my viewpoint w.r.t.
formal languages (grammars) I think.
To reiterate, content models (i.e., the specific technology
in XML, regular expressions on the child axis where there
is no first-class way to label parts of content models)
desribe superficial syntax only. They can describe the superficial
syntax, and define validation. But content models do not
necessarily define a markup language: they may hide as
much as they describe.
Rick Jelliffe
The XML & SGML Cookbook: Recipes for Structured Information
Charles F. Goldfarb Series on Structured Information Management
Prentice Hall, 650 pages + CD-ROM
ISBN 0-13-614223-0
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)
From digitome at iol.ie Mon Sep 20 13:29:09 1999
From: digitome at iol.ie (Sean Mc Grath)
Date: Mon Jun 7 17:15:17 2004
Subject: Groves, IsNess and the Generic Data Object. [was.. Another
try on Groves]
Message-ID: <3.0.6.32.19990920121630.00ac8d50@gpo.iol.ie>
Graham,
Thanks for this post. I think this is a useful
discussion...
[Graham Moore]
>I saw the following from Sean
>
>>>I believe it makes perfect sense to *think* of MPEGS, PDFs,
>>> whatever, in XML terms.
>
>This is NOT what groves are about. Groves are about thinking about the
>'IsNess' of things.
>
>XML is one thing you could get as a serialisation of a grove model.
>
>Consider..
>
>root node
>|
>----- named prop 1 - type node
> |
> ----- named prop 2 - type basic
> |
> |
> ----- named prop 3 - type basic
>|
>|
>----- named prop 4 - type node
> |
> ----- named prop 5- type basic
> |
> |
> ----- named prop 6 - type basic
>
>
>Above is the abstract data model for a thing. It could be any thing. There
>is NO XML I have
>just captured the 'IsNess' the first class properties of the thing. I have
>not thought about XML I have thought about the properties of the thing.
In the above you have done what any intelligent, carbon based
life form known to man would have done -- you have structured
a domain model into a *hierarchy* of objects. I look at
your diagram and in my head I see nodes called "named prop 1"
and "named prop 4". I see other nodes that are contained
within these nodes called "named prop 2" and so on.
That level of abstraction -- nodes -- is all I need to
process this data -- given some simple API. XML
provides such a simple API. I need to simply
mentally map the nodes and arcs into XML
terminology of elements and attributes. This
done, I can write software apace
using SAX, DOM or any other XML API.
Lets pretend the above data is in a data format
known as FOO and accessible in CORBA land via
a FOO-API. You seem to be asserting
that I need a "grove" for this because the
property set mechanism of the grove paradigm
allows me to work in terms of an object
API rather than an XML API. In other
words this:
# Access instance variable "named prop 5"
# of object "named prop 4"
named prop 4.named prop 5
instead of this:
(or its equivalent (ontological arguments aside))
...
I don't buy it. I personally do not find the prospect of
programming the latter rather than the former in any way
daunting or limiting. It is a trivial transformation to
take a hierarchy of typed nodes and associated attributes
and create an object hierarchy if I really want to be able
to use "object.instance attribute" syntax.
>
>Now, if I decided that I need a serialisation of my grove then I need
>to choose a mechanism for that. Section A1.4.5 of HyTime 2nd Edition
>provides us with the
>canonical representation for doing such a thing.
>
>Obviously the canonical representation is defined in terms of an SGML DTD
>and thus I could
>create XML and SGML instances for my grove model. Equally though I could
>serialise the model as
>an S-Expression.
>
Agreed.
>I think the point is that the grove paradigm should not get people to think
>in terms of XML
>but in terms of better appreciation of the properties of the notations they
>are dealing with.
This is where I think you have misunderstood my position. As human
beings we have a cognitive pre-disposition to thinking in terms
of hierarchies. There are many, many ways to represent such
hierarchies syntactically - C++ programs, SGML, S-Expressions,
tortuously inter-linked relational database tables, CODASYL,
STEP and of course XML.
They are all basically syntactic sugar. The hierarchy exists
independently of any syntactic form used to give it a digital
rather than cognitive form. XML has a nice simple syntactic
representation for hierarchies. It uses certainly terminology
to do that - elements and attributes. This terminology leads
naturally to an API for hierarchies that uses terms like:
startElement
attributeList
and so on.
This API is all you need to process arbitrary hierachies
of data. It is *not* a pre-condition of programming
to this API that the data must have been previously
serialized in XML notation!
Earlier in talking about "IsNess" you say:
>There is NO XML
This is exactly my point! XML is syntax for representing
a hierarchy. This syntax leads naturally to an API
that is couched in terms of elements/attributes. This
API is the key. You do not *need* to serialize data
to XML syntax in order to use this API.
>
>I agree that the concept that groves can be seen as a way to add tags to
>untaggable data as
>very powerful. But the more general case is that the grove paradigm gives
>names and first
>classness to otherwise unaddressable properties.
>
I see it as a trivial transformation to convert a
hierarcy of elements and attributes into a
collection of objects with associated instance
variables.
I believe this has been done on
numerous occasions in the SGML world. I think
it was Bob duCharme who wrote a paper about
transforming SGML instances into object hierarcies
using Smalltalk as the implementation language.
Some time ago, I prototyped an algorithm to do it
in Python but I never got around to implementing
it because I never saw the benefit of it for
my work. Having said that, I do not work with
STEP or CAD system data where I guess such
a model transformation would be more useful.
[...]
>It is the concrete focus that I want to start with,
>
>The most striking difference between XML and a Grove Model is that in the
>domain of 'cars' an Grove will let you access the value of the 'door'
>property, the grove for the XML representation of the car will let you
>access an 'attribute' of an element that is a serialisation of the object
>'door'. As Paul said, Groves remove a level of redundant indirection.
But this transformation is trivial! I guess I am having
difficult seeing why I need to employ the vast edifice
of abstraction that is the "grove paradigm" in order
to do this.
Somewhere along the line someone seems to have had
an "Aha!" moment which went like this
"...ergo we need groves".
It is the "..." bit that I do not see.
regards,
Developers Day co-Chair WWW9, April 2000, Amsterdam
http://www.www9.org
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)
From Mark.Birbeck at iedigital.net Mon Sep 20 13:34:20 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun 7 17:15:18 2004
Subject: Groves, IsNess and the Generic Data Object. [was.. Another tr
y on Groves]
Message-ID:
I feel a bit sorry for the grove guys, because as is usual in our
nerd-world, we never have discussions that go:
A: Hey, how about this?
B. Wow, great idea but 'fraid it will have to wait.
A: That's no problem. Nice talking to you.
We always have:
A: Hey, you must do this or your edifice will collapse.
B: No, who needs it, it's only for geeks.
A: You're only saying that because you are:
(a) a member of the establishment
(b) funded by Microsoft
B: You're only saying that because you are:
(a) a member of the establishment
(b) funded by Microsoft
A: Why doesn't anyone listen to me?
B: Pardon?
And so on.
It seems pretty straightforward to me that if you can accept a paradigm
that abstracts collections of data into nodes, then you can accept an
abstraction that allows those nodes to be manipulated in a manner that
is closer to the structure of the original data. In other words, if you
can accept that the transformation of:
Fred
25/12/0000
into:
sName = doc.children.item(1).children.item(1)
is useful - because you can begin to generalise solutions, hide the
parsing, and so on - then why not accept that:
sName = doc.author(1).name
is even more useful? And what about?:
iAge = doc.author(1).age()
If you were writing a serious bullet-proof application you would
probably put a layer over the DOM which allows you to manipulate
'author' objects in this way anyway. You'd create some Java or C++
classes that sit on top of the DOM, and have to invoke the right one
depending on the element type of the node you were currently
manipulating. As far as I can tell from a quick reading, all the grove
fans are saying is that just as you give everyone a parser and node
walker in the API, now let's give them access to the objects, 'as
objects' and not as nodes. This extra layer of code would then become
much simpler.
Now, I don't think this should hold up the onward march of XML; there is
no way that everyone is ready for this 'paradigm shift' anyway. But
whether we are ready or not shouldn't prevent us from having a useful
discussion. People are being a bit lazy by dismissing the approach with
"I'm quite happy walking the DOM" and "It's not that difficult to use
the XML API".
It doesn't seem that radical (or scary) to me, to say that at some point
in the future an approach like groves will be an extremely common way of
manipulating data. But I also don't think I'll lose my shirt if I bet
that for now though, the initial advances made by XML and nodes will be
more than enough to keep us going.
Best regards,
Mark
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)
From simonstl at simonstl.com Mon Sep 20 13:38:31 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:18 2004
Subject: Another look at namespaces
In-Reply-To: <001d01bf0344$a8740b20$0300000a@cygnus.uwa.edu.au>
References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU>
<199909181437.KAA05856@hesketh.net>
<199909191543.LAA26903@hesketh.net>
<199909200555.BAA18874@hesketh.net>
Message-ID: <199909201140.HAA27411@hesketh.net>
At 04:46 PM 9/20/99 +0800, James Tauber wrote:
>> Meaning one grammar + vocabulary -> language? Where the quantities are all
>> one?
>
>You don't actually need the "vocabulary". The alphabet of a formal language
>is part of the grammar.
In XML-based languages that rely on DTDs or schemas, yes. But in all
formal languages? Seems that it wouldn't be hard to create a formal
language that had classes of vocabulary (like noun, verb, adjective) and
fit them into patterns (subject[noun]-verb[verb]-object[noun]) that were
separate. Hopefully, it wouldn't look like English, but it does seem like
a practical solution to a lot of problems.
>> I think in practice you may find multiple grammars used within the
>> same language, even a formal one
>
>Ahh. But now you are using "language" in a way other than "the set of
>utterances generated by the grammar" right? Unless you mean that sometimes
>the same syntactic rules can be expressed two different ways eg
>
>a+
>
>versus
>
>a a*
It's that, but it's also worse. Suppose you have a nice modular DTD that
expresses most of the vocabulary a user will need to create documents of a
certain type, but has ANY sections so that users can organize it any way
they like. Users build sets of DTDs to see what exactly it is they're
getting or producing, but all of the possibilities are actually open. Is
the language described by the 'master' DTD, which doesn't get you very far?
Or is the language described by the particular DTDs? Or do we measure
interoperability? A 'master DTD' containing all possibilities will quickly
grow obese.
Then there's the simpler case of well-formed documents, for which we can
_derive_ grammars, but can't make definitive statements above the level of
XML 1.0 conformance.
>> and (yuck for some) not just subsets (once you let ANY in the door, it all
>goes). Trying to keep it all
>> exclusively singular seems to be a common dream throughout computing, but
>> one I hope we can leave behind more and more over time.
>
>Let me stress again, I am not saying you can always have a single grammar
>for a particular "language". I am saying that you can have a single grammar
>for a particular "formal language in the sense used by Paul".
I think 'formal language' in that sense is not especially useful except for
limited situations, and should probably be reserved for the few cases where
XML development is limited to representations of older legacy systems that
relied on formal languages based on that sense. XML itself, it seems, can
do better than that.
>> I think we might do well to ponder whether XML is really about creating
>> formal languages or for encoding information already represented in
>natural
>> languages. If it's the latter, the results might be more interesting.
>
>Why can't it be both? Isn't that the whole point of write schemata
>(including DTDs)? Isn't it about formalising the encoding of this
>information.
It depends on what kind of 'formalizing' you want to do. In many cases,
I'd suggest that we focus on 'relaxing', producing more flexible models
that aren't so concerned about locking everything down into a single
grammar and a single vocabulary. It requires a change of mindset.
Why is it that only one validating Java parser allows the application to
continue after a validity constraint (not a well-formedness constraint) has
been violated? I suspect it's because a lot of folks are taking the
'formal grammar' of DTDs more seriously than the XML 1.0 spec itself
does... [See David Brownell's report on XML.com at
http://www.xml.com/pub/1999/09/conformance/summary.html]
I don't think we're incompatibly far apart, I just would like folks to look
at 'formal languages' a bit more closely and a bit more critically. Rick
Jelliffe's made excellent arguments in other postings on this thread, for
example, regarding the ways formal languages can obscure as well as
illuminate.
Right now, I think we need to contemplate whether 'formal grammars'
sufficiently distinguish 'languages' in practice before putting extra work
for programmers and authors (namespaces) on every formal grammar that comes
our way.
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From Nigel.Robbins at macro4.com Mon Sep 20 13:44:11 1999
From: Nigel.Robbins at macro4.com (Nigel Robbins)
Date: Mon Jun 7 17:15:18 2004
Subject: Expat - basic help
Message-ID: <99Sep20.124651bst.26110@gateway.macro4.com>
I need a stack mechanism that keeps track of the current context.
For example, in the following XML, I need to distinguish between the two
different tags.
Some different text...
I was thinking of putting in a stack mechanism via the
"XML_SetElementHandler" function.
Does anyone have any example code I can have a look at ?
Many thanks,
Nigel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990920/d9e3b370/attachment.htm
From jtauber at jtauber.com Mon Sep 20 14:11:04 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun 7 17:15:18 2004
Subject: Another look at namespaces
References: <009f01bf0350$92a66a70$41f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <003401bf0360$ddee7800$0300000a@cygnus.uwa.edu.au>
> This distinction, that the Document Type Definition is not the same as the
markup declarations, is as old as
> SGML.
SGML makes the distinction and I think it is a good one but I don't think
XML does. In XML a DTD is the (formal)grammar defined by the markup
declarations and no more.
In SGML, Document Type Definition = names + syntax + semantics
In XML, Document Type Definition = names + syntax
(NOTE: I'm separating names and syntax to emphasis the distinction between a
choice of name for an element type and a choice of syntactic contraint.
Arbitrariness of the linguistic sign and all that)
Perhaps we need a word for names + syntax + semantics in XML.
Some people use "XML vocabulary" for this and others use "XML vocabulary" to
mean a set of element and attribute names along with their semantics (ie
little or no syntax).
Whether one views:
vocabulary = names + semantics
or
vocabulary = names + syntax + semantics
possible determines their standing on the number of namespaces XHTML 1.0
should have.
James
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)
From dave at userland.com Mon Sep 20 14:29:21 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun 7 17:15:18 2004
Subject: Announce: Prefs distribution thru XML-RPC
Message-ID: <04e801bf0364$a2912f60$1618ccce@pebbles>
Suppose you have a website that is distributed across several machines,
perhaps geographically, with some or all of them serving dynamic pages with
per-user customization. You want to provide a single place for the user to
set preferences and have the changes percolate to the other servers on your
internal network.
We had to build such a prefs distribution network for UserLand.Com, and
naturally we used XML-RPC to implement it.
The interface is easy to implement once you have an XML-RPC layer running.
It consists of a single RPC handler, updateMemberInfo, on each of the
affiliate machines. It's a little more complicated on the prefs hub -- it
has to implement a database of affiliated machines, and call each machine
when a preference is updated. On either side, it's a very easy
implementation and it delivers a feature that users want.
Like all the next-level-up specs we're doing for XML-RPC the focus is on
simplicity, and should work equally well with SOAP or other transport-level
protocols.
***Pointers
The specification is here:
http://www.xmlrpc.com/stories/storyReader$496
The Frontier implementation is here:
http://frontier.userland.com/stories/storyReader$1484
Dave Winer
UserLand Software
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)
From ricko at allette.com.au Mon Sep 20 14:52:26 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:18 2004
Subject: Another look at namespaces
Message-ID: <00ea01bf0367$df125a60$41f96d8c@NT.JELLIFFE.COM.AU>
From: James Tauber
>> This distinction, that the Document Type Definition is not the same
as the
>> markup declarations, is as old as SGML.
>
>SGML makes the distinction and I think it is a good one but I don't
think
>XML does. In XML a DTD is the (formal)grammar defined by the markup
>declarations and no more.
Sure, in XML "This grammar is known as a document type definition, or
DTD."
But that just means that in XML we have to use some other term instead
of
"document type", for example "language". It does not alter my point.
>Whether one views:
>
> vocabulary = names + semantics
>or
> vocabulary = names + syntax + semantics
>
>possible determines their standing on the number of namespaces XHTML
1.0
>should have.
I think
namespace = names
vocabularies = names in namespaces + semantics possibly
(I can have a vocabulary composed of names from different
namespaces)
syntactic schema = names in namespaces + syntax
(e.g. XML DTD)
language = names + syntax + semantics
(where the syntax ideally uses some grammar that actually
captures the
amount of cohesion between elements.)
Actually, there should be a difference distinguished between a model and
a schema. The schema captures/describes everything about a syntax; the
model merely captures/describes everything convenient. So the
statecharts
in UML allow guard conditions, to allow extensibility: constraints which
don't fit into the grammar types allowed by UML statecharts can be
notated still.
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/ 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)
From ann at webgeek.com Mon Sep 20 15:17:22 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:18 2004
Subject: Statement from HTML WG
Message-ID: <4.1.19990920091625.02546e70@mail.webgeek.com>
Date: Fri, 17 Sep 1999 18:14:14 +0200 (MET DST)
Message-Id:
From: Steven Pemberton
To: ann@hwg.org
Subject: XML-DEV
X-UIDL: 918589418
Status: U
Ann,
I tried to send this to xml-dev, but apparently I can't if I'm not
subscribed.
Could you please post it there for me?
Thanks!
Steven
>From steven Thu Sep 16 15:02:06 1999
Date: Thu, 16 Sep 1999 15:02:06 MET DST
From: Steven Pemberton
To: xml-dev@ic.ac.uk
Cc: w3c-html-wg@w3.org
Subject: XHTML: One Namespace or Three?
(I don't know if I can post to this list, since I'm not subscribed)
I've been told that an opinion has been voiced in this group that
there is a conspiracy within the HTML Working group with regards three
namespaces, or that we are somehow working in secrecy.
That is not the case, but unfortunately xml-dev isn't one of our
standard communication channels.
To try and explain how the HTML WG came to the decision it did, I
enclose a document below that outlines the process we went
through. You'll see that we did approach the XML community on the
issue (via the xml-plenary list), and there was not a single answer
from the community.
I hope this document helps.
As I said, I'm not subscribed to this group, though members of the WG
are, who keep me in touch with what is being said. I already receive
more email per day than I can read in a day, so please be
understanding about any sluggishness in replies if you email me
directly.
Best wishes,
Steven Pemberton
Chair, W3C HTML WG
XHTML: One Namespace or Three?
Steven Pemberton
This document discusses the reasoning behind why the XHTML 1.0 PR
[http://www.w3.org/TR/xhtml1/] uses three namespaces.
Executive summary: Namespaces are used by software to distinguish what
is contained in a piece of markup. There are use-cases to support both
a single-namespace solution and a three-namespace solution: some
software cares which version of XHTML is being used, and some
doesn't. Three namespaces makes life harder for software that doesn't
care, but allows software that does care to do its work. A single
namespace makes life easier for software that doesn't care, but
prevents software that does care from doing its job. If the XML
community says that the use cases that support three namespaces are
not important, the HTML WG are willing change their mind.
What are Namespaces
In the short introductory section on motivation in The Namespace
recommendation [http://www.w3.org/TR/1999/REC-xml-names-19990114/]
it is said:
[Documents] containing multiple markup vocabularies, pose
problems of recognition and collision. Software modules need
to be able to recognize the tags and attributes which they are
designed to process, even in the face of "collisions"
occurring when markup intended for some other software package
uses the same element type or attribute name.
The only definition of a namespace the recommendation gives is:
[Definition:] An XML namespace is a collection of names,
identified by a URI reference [RFC2396], which are used in XML
documents as element types and attribute names.
So, according to the Namespace recommendation, Namespaces are used to
disambiguate different vocabularies, without saying where those
vocabularies come from. In other words, it is up to the designer of
the namespace itself to specify what the vocabulary is.
History
In the first public draft for XHTML 1.0
[http://www.w3.org/TR/1998/WD-html-in-xml-19981205/], we used three
namespaces, since we foresaw use-cases that made distinguishing the
three different vocabularies useful (see below).
After publishing the draft we received two comments (though without
technical argumentation) saying that there should only be one
namespace. Assuming we had misunderstood how namespaces were intended
to work, as a response to this we went to one namespace. To this we
got further (verbal) comments, with technical reasoning, that it
should really be three after all. Since this was the majority of the
group's feeling as well, we went back to our original decision, though
this time using hierarchically structured namespaces, in an attempt to
address both groups.
Since we were getting different messages from the XML Community, we
also asked the XML Plenary group to discuss the issue. This (long)
discussion starts at
[http://lists.w3.org/Archives/Member/w3c-xml-plenary/1999Jul/0017.html].
(See the end of this document for some selections.) The result of these
discussions seems to show that there isn't consensus on the issue,
with people arguing quite strongly for both positions.
Using Namespaces
The only place where the distinction between using one namespace and
using three is important is when including fragments of xhtml in
another document. You can include a namespace at the top of a
document, but there are other mechanisms available at that point for
distinguishing the markup used, for the namespace not to be important.
However, in a fragment such as the following:
This is also available
online .
the namespace is the only mechanism available for identifying the
vocabulary intended.
As has been shown in the xml plenary mailing list, there are use-cases
for both alternatives; in other words there are processors that don't
care exactly which xhtml vocabulary is being used, and whose life is
easier if it only has to look for one namespace, and there are
processors that do care, and want to be able to distinguish. (You can
liken this to English-language processors: hyphenation algorithms
don't need to know if you are using American English or British
English; spelling checkers do).
So in the light of valid use-cases for both positions, the different
use-cases need to be evaluated to see which solution is preferable.
The HTML WG opted for three namespaces on the grounds that one
namespace makes one of the classes of use-case impossible, whereas
three namespaces allows both, only making one of the classes harder to
do.
(Please note that this is independent of whether the Namespace URI be
used to refer to a Schema of some sort; there are those who argue that
different Schemas imply different Namespaces, and therefore XHTML
should have three namespaces; the HTML WG does not have an official
position on that issue).
However, the HTML WG is not bound irrevocably to three namespaces. We
want XHTML to be a good XML citizen, and if the consensus of the XML
community is that the 3-namespace use-cases are not important and can
reasonably be ignored, we are willing to go with that consensus.
Steven Pemberton,
Chair, W3C HTML WG
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From jtauber at jtauber.com Mon Sep 20 15:21:07 1999
From: jtauber at jtauber.com (James Tauber)
Date: Mon Jun 7 17:15:18 2004
Subject: Another look at namespaces
References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU><199909181437.KAA05856@hesketh.net><199909191543.LAA26903@hesketh.net><199909200555.BAA18874@hesketh.net> <199909201140.HAA27411@hesketh.net>
Message-ID: <004501bf036a$b8e511e0$0300000a@cygnus.uwa.edu.au>
----- Original Message -----
From: Simon St.Laurent
> >You don't actually need the "vocabulary". The alphabet of a formal
language
> >is part of the grammar.
>
> In XML-based languages that rely on DTDs or schemas, yes. But in all
> formal languages?
Yes. The grammar includes the symbols it uses.
> Seems that it wouldn't be hard to create a formal
> language that had classes of vocabulary (like noun, verb, adjective) and
> fit them into patterns (subject[noun]-verb[verb]-object[noun]) that were
> separate.
This separation is merely partitioning the grammar into productions that
take penultimate symbols to terminal symbol and all the other productions.
Eg
[1] Sentence -> NP VP
[2] VP -> V NP
[3] NP -> Simon
[4] NP -> XML
[5] V -> likes
What you are talking about is splitting productions 3-5 from 1-2. This is
often done in natural language processing and many theories of (natural)
language make a distinction between the lexicon and the syntactic rules. But
we are talking about formal languages, not natural languages.
[..]
> It's that, but it's also worse. Suppose you have a nice modular DTD that
> expresses most of the vocabulary a user will need to create documents of a
> certain type, but has ANY sections so that users can organize it any way
> they like. Users build sets of DTDs to see what exactly it is they're
> getting or producing, but all of the possibilities are actually open. Is
> the language described by the 'master' DTD, which doesn't get you very
far?
> Or is the language described by the particular DTDs? Or do we measure
> interoperability? A 'master DTD' containing all possibilities will
quickly
> grow obese.
I'm not sure I understand what you are saying here. When a user pieces
together bits of different DTDs, they end up with a *single* DTD. This is a
single grammar definining a single set of valid instances.
> Then there's the simpler case of well-formed documents, for which we can
> _derive_ grammars, but can't make definitive statements above the level of
> XML 1.0 conformance.
Pardon? A grammar for well-formed documents doesn't need to be derived
because it is in the XML 1.0 REC. It is a BNF augmented by WFCs and the odd
bit of prose.
[...]
> I think 'formal language' in that sense is not especially useful except
for
> limited situations, and should probably be reserved for the few cases
where
> XML development is limited to representations of older legacy systems that
> relied on formal languages based on that sense. XML itself, it seems, can
> do better than that.
It can. But formal languages are part of the picture because sometimes there
are syntactic constraints. They might be loose, but they are still a
grammar.
> It depends on what kind of 'formalizing' you want to do. In many cases,
> I'd suggest that we focus on 'relaxing', producing more flexible models
> that aren't so concerned about locking everything down into a single
> grammar and a single vocabulary. It requires a change of mindset.
A formal grammar is still a formal grammar even if it permits any of the
terminal symbols in any order. A more flexible model is still a model. The
moment you model the syntax, you have a formal grammar.
> Why is it that only one validating Java parser allows the application to
> continue after a validity constraint (not a well-formedness constraint)
has
> been violated?
Because the others are wrong.
> I suspect it's because a lot of folks are taking the 'formal grammar' of
DTDs more seriously than the XML 1.0
> spec itself does...
But that has nothing to do with the value of formal grammars. If I present
you with a CFG modelling English and refuse to listen to you unless your
sentences parse to my CFG, that isn't a problem with my CFG *or* the notion
of CFGs in general.
> I don't think we're incompatibly far apart
I actually agree with you completely in pretty much everything but
terminology.
> I just would like folks to look at 'formal languages' a bit more closely
and a bit more critically. Rick
> Jelliffe's made excellent arguments in other postings on this thread, for
example, regarding the ways formal
> languages can obscure as well as illuminate. Right now, I think we need to
contemplate whether 'formal
> grammars' sufficiently distinguish 'languages' in practice before putting
extra work
> for programmers and authors (namespaces) on every formal grammar that
comes
> our way.
I think the XML community would generally agree that:
1. certain classes of formal grammar are not sufficient for the syntactic
constraints people wish to express
2. syntax isn't all there is
Linguists worked these out well before you and I were born, Simon :-)
I think SGMLers did too which is one of the reasons that a Document Type
Definition in SGML includes semantics as well as syntax (see another post
where I follow on from Rick's comments relating to this)
As far as I can tell, no one is arguing that formal grammars are all we
need. I am merely trying to clarify what formal grammars are so that people
understand what is meant when someone says that a language has a grammar or
that a DTD is a grammar.
James
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)
From srn at techno.com Mon Sep 20 15:31:20 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun 7 17:15:18 2004
Subject: W3C's 'Moral Majesty'
In-Reply-To: <3.0.32.19990919115750.0120e420@pop.intergate.bc.ca> (message
from Tim Bray on Sun, 19 Sep 1999 12:14:06 -0700)
References: <3.0.32.19990919115750.0120e420@pop.intergate.bc.ca>
Message-ID: <199909201328.IAA05813@bruno.techno.com>
[Tim Bray:]
> Namespaces are a facility to make names universal, no more, no less.
They don't accomplish that goal. Now that we've done away with the
requirement that there be a DTD, surprise! we still need models.
Namespaces, however, are not models, and the actual model that you
must know, in order to be able to write software to work with a
namespace, doesn't have to be published in order to be used. So, now
we have a situation in which software vendors can benefit from the
sheer secrecy of their information architectures. This is progress?
I don't think so. In terms of the public interest, this is a huge
step backwards. This is precisely the opposite outcome from the
reason why I have devoted 14 years of my life to generalized markup.
> Making the names that populate that markup universal, so that
> vocabularies can freely be mixed, simply adds robustness to the
> system in the face of the fact that the days of the Great
> Centralized Committee-Built DTD In The Sky are over (good
> riddance). -Tim
If vocabularies can be *freely* mixed, then they have no internal
structuring requirements in order to make sense. Any name can appear
anywhere at all, including inside elements from the same namespace
where they don't make sense according to the (unpublished and, at this
point in time, unpublishable) requirements of that namespace. So now
we have a situation in which there is no basis for syntactic
validation. The whole business of what constitutes syntactic validity
can be a secret between those who met to make a Great Centralized
Committee-Built DTD In The Sky (but instead of calling it a DTD, it's
called a "namespace" -- something that has no formal existence). This
is not progress, and it's not robustness, either. In terms of the
public interest, this is a huge step backwards.
-Steve
--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com http://www.techno.com ftp.techno.com
voice: +1 972 231 4098
fax +1 972 994 0087
pager (150 characters max): srn-page@techno.com
3615 Tanner Lane
Richardson, Texas 75082-2618 USA
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)
From david at megginson.com Mon Sep 20 15:53:45 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:18 2004
Subject: W3C's 'Moral Majesty'
In-Reply-To: <199909201328.IAA05813@bruno.techno.com>
References: <3.0.32.19990919115750.0120e420@pop.intergate.bc.ca>
<199909201328.IAA05813@bruno.techno.com>
Message-ID: <14310.15611.395555.890916@localhost.localdomain>
Steven R. Newcomb writes:
> [Tim Bray:]
>
> > Namespaces are a facility to make names universal, no more, no
> > less.
>
> They don't accomplish that goal. Now that we've done away with the
> requirement that there be a DTD, surprise! we still need models.
!!!
No, they *do* accomplish that goal -- people have raised reasonable
concerns about the persistence of Namespace-qualified names
(especially with URLs), but no one has yet introduced a credible
argument that Namespace-qualifed names are not universal.
Rather, Steve is arguing that universal names should not be an end in
themselves -- and that's a very reasonable argument -- but that hardly
disproves the claim that Namespace-qualified names are
universally-distinguishable.
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From ann at webgeek.com Mon Sep 20 16:07:17 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:18 2004
Subject: W3C's 'Moral Majesty'
In-Reply-To:
References: <199909191719.MAA03613@bruno.techno.com>
Message-ID: <4.1.19990920100639.0268c670@mail.webgeek.com>
At 07:06 PM 9/19/99 +0100, Dan Brickley wrote:
>
>On Sun, 19 Sep 1999, Steven R. Newcomb wrote:
>
>[sniiiippppp]
>
>> [...] The W3C is a software vendor consortium; people (including W3C
>> members) who believe otherwise are deluding themselves.
>[...]
>
>I'm sorry, I can't let this one just slip past. As Bristol University's
>Advisory Committee representative to W3C, I can assure you that agendas
>other than software vending are represented. Bristol University may be
>many things, and there are many groups here who do produce saleable
>software, but we're not software vendors. We joined W3C to participate
>in the development of specifications that affect teaching, learning and
>research applications in our *.ac.uk environment. And we're not alone
>in this...
Well put.
Ann (this time indeed speaking as the HWG AC rep)
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From ann at webgeek.com Mon Sep 20 16:10:30 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:18 2004
Subject: W3C's 'Moral Majesty'
In-Reply-To: <199909191900.PAA32396@hesketh.net>
References:
<199909191719.MAA03613@bruno.techno.com>
Message-ID: <4.1.19990920100826.02570ac0@mail.webgeek.com>
At 03:03 PM 9/19/99 -0400, Simon St.Laurent wrote:
>One key area of 'consumers' that I don't see represented as W3C members is
>open source software developers
The Open Group is a member of the W3C. And indeed until his recent job
change, Shane McCarron was their AC rep and participant on the HTML WG (the
later being something he continues now as an invited expert).
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From ann at webgeek.com Mon Sep 20 16:20:06 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:18 2004
Subject: an unfilled need
In-Reply-To: <00c701bf02dd$571ed690$42f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <4.1.19990920101807.02571400@mail.webgeek.com>
At 04:27 AM 9/20/99 +0800, Rick Jelliffe wrote:
>> Rick Jelliffe:
>>>There is no W3C method to declare which schema should be
>>>used, akin to the stylesheet declaration.
>
>> Yes there is: resolution of the schema URI.
>
>Tim is saying that using the namespace URI to specify a schema
>is the official W3C method.
No. Tim has been very careful to state that he is posting as himself -- his
individual opinions.
>On the contrary "It is not a goal that it [the namespace URI] be
>directly usable for retrieval of a schema (if any exists)" says
>XML NS.
Not the goal, as has repeatedly been said, by more experts (of expert
stature than myself), "not a goal" does not equate to "cannot be done".
That may very well have been the intent of that statement, but it doesn't
say that, and language commonly used in specs to provide for such
proscriptions was not used.
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From simonstl at simonstl.com Mon Sep 20 16:35:58 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:19 2004
Subject: W3C's 'Moral Majesty'
In-Reply-To: <4.1.19990920100826.02570ac0@mail.webgeek.com>
References: <199909191900.PAA32396@hesketh.net>
<199909191719.MAA03613@bruno.techno.com>
Message-ID: <199909201437.KAA02287@hesketh.net>
At 10:10 AM 9/20/99 -0400, Ann Navarro wrote:
>At 03:03 PM 9/19/99 -0400, Simon St.Laurent wrote:
>
>>One key area of 'consumers' that I don't see represented as W3C members is
>>open source software developers
>
>The Open Group is a member of the W3C. And indeed until his recent job
>change, Shane McCarron was their AC rep and participant on the HTML WG (the
>later being something he continues now as an invited expert).
Er... so far as I've seen, the Open Group isn't a bastion of Open Source
software. It's a consortium like the W3C, although it goes so far as to
have a 'sales team' for membership questions. Registration is a minimum
requirement for access, and that doesn't get you far. A search for open
and source (through the advanced search, not the simple, which sticks you
with an or) finds very little 'open source'.
While they do release some software with source, even free, they aren't
'open source' in the commonly understood (though often-debated) sense of
the Open Source Initiative (www.opensource.org) or the Free Software
Foundation (www.fsf.org).
Open source in these senses remains poorly served by the W3C's process (and
probably by the Open Group's process as well, from what I can gather on
their site.)
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From simonstl at simonstl.com Mon Sep 20 16:37:39 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:19 2004
Subject: Another look at namespaces
In-Reply-To: <004501bf036a$b8e511e0$0300000a@cygnus.uwa.edu.au>
References: <006101bf0066$a339c680$1ff96d8c@NT.JELLIFFE.COM.AU>
<199909181437.KAA05856@hesketh.net>
<199909191543.LAA26903@hesketh.net>
<199909200555.BAA18874@hesketh.net>
<199909201140.HAA27411@hesketh.net>
Message-ID: <199909201440.KAA02439@hesketh.net>
I think you're confusing my discussion of grammars you can build on top of
XML with XML's foundational grammar, which I earlier compared to an alphabet.
At 09:18 PM 9/20/99 +0800, James Tauber wrote:
>> Seems that it wouldn't be hard to create a formal
>> language that had classes of vocabulary (like noun, verb, adjective) and
>> fit them into patterns (subject[noun]-verb[verb]-object[noun]) that were
>> separate.
>
>This separation is merely partitioning the grammar into productions that
>take penultimate symbols to terminal symbol and all the other productions.
>
>Eg
> [1] Sentence -> NP VP
> [2] VP -> V NP
> [3] NP -> Simon
> [4] NP -> XML
> [5] V -> likes
>
>What you are talking about is splitting productions 3-5 from 1-2. This is
>often done in natural language processing and many theories of (natural)
>language make a distinction between the lexicon and the syntactic rules. But
>we are talking about formal languages, not natural languages.
True, except that by taking this approach you can leave the grammar _open_
- allowing extension by adding new objects that are nouns, verbs, etc. You
don't have to define the complete grammar in advance. XML 1.0 only permits
a limited subset of this functionality through parameter entities, which
can be twisted into powerful tools.
I think both natural and formal languages can be built to be 'extensible'
in a very broad sense of the term, with less constraint by formal grammar
than you appear to be proposing.
>I'm not sure I understand what you are saying here. When a user pieces
>together bits of different DTDs, they end up with a *single* DTD. This is a
>single grammar definining a single set of valid instances.
So overlapping multiple DTDs don't exist? Even if, in fact, they may be
interoperable on multiple levels? I also like Rick's example of
architectural forms, which permit validation of the same document against
multiple constraint sets.
>> Then there's the simpler case of well-formed documents, for which we can
>> _derive_ grammars, but can't make definitive statements above the level of
>> XML 1.0 conformance.
>
>Pardon? A grammar for well-formed documents doesn't need to be derived
>because it is in the XML 1.0 REC. It is a BNF augmented by WFCs and the odd
>bit of prose.
I'm discussing the grammar of the content built on top of XML, not the XML
itself. The content of a well-formed document is pretty nearly infinitely
extensible, without a grammar that describes content models, vocabulary,
etc. This is where I think you're confusing my discussion of what you can
do on top of XML 1.0 with discussion of XML 1.0 itself.
>It can. But formal languages are part of the picture because sometimes there
>are syntactic constraints. They might be loose, but they are still a
>grammar.
But is that grammar interesting any more, or is it like letters? Something
you pay close attention to in elementary (grammar) school, and move beyond
as you build more things on top of them.
>> It depends on what kind of 'formalizing' you want to do. In many cases,
>> I'd suggest that we focus on 'relaxing', producing more flexible models
>> that aren't so concerned about locking everything down into a single
>> grammar and a single vocabulary. It requires a change of mindset.
>
>A formal grammar is still a formal grammar even if it permits any of the
>terminal symbols in any order. A more flexible model is still a model. The
>moment you model the syntax, you have a formal grammar.
That's fine, as a foundation (XML 1.0), but do we want to be stuck with
this approach at higher levels? 'Modeling the syntax' does produce formal
grammars - but modeling that syntax doesn't automatically produce something
useful or necessary.
>> I don't think we're incompatibly far apart
>
>I actually agree with you completely in pretty much everything but
>terminology.
We seem to continue to disagree on the terminology, but agree that the
terminology is important.
>I think the XML community would generally agree that:
>
>1. certain classes of formal grammar are not sufficient for the syntactic
>constraints people wish to express
>2. syntax isn't all there is
Then we've probably reached the end of the discussion - I think we can
agree on this pretty reasonably.
>Linguists worked these out well before you and I were born, Simon :-)
>I think SGMLers did too which is one of the reasons that a Document Type
>Definition in SGML includes semantics as well as syntax (see another post
>where I follow on from Rick's comments relating to this)
SGML wasn't fond of leaving things open, however. XML blasted open the
option of life without DTDs, giving us the possibility of neither semantics
nor syntax (at least on the level of content models and constraints on
vocabulary.)
>As far as I can tell, no one is arguing that formal grammars are all we
>need. I am merely trying to clarify what formal grammars are so that people
>understand what is meant when someone says that a language has a grammar or
>that a DTD is a grammar.
I'm not sure that the clarification is actually useful, as I've stated
before. Thinking about formal grammars for XML seems to have a creeping
effect on the structures we propose for using XML. Unless we can move
beyond the vision of a model for everything, I don't think we're going to
get real far.
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From ricko at allette.com.au Mon Sep 20 16:52:33 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:19 2004
Subject: Statement from HTML WG
Message-ID: <011901bf0378$a8db81e0$41f96d8c@NT.JELLIFFE.COM.AU>
From steven Thu Sep 16 15:02:06 1999
>Using Namespaces
>
>The only place where the distinction between using one namespace and
>using three is important is when including fragments of xhtml in
>another document.
A document processor can tell if a name has been used which it doesnt
understand
when it comes to that offending element. Otherwise we get the ludicrous
position
that a strict HTML processor will reject
This is also available
online .
while accepting
This is also available
online .
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/ 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)
From srn at techno.com Mon Sep 20 16:59:12 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun 7 17:15:19 2004
Subject: Another look at namespaces
In-Reply-To: <199909200538.AA02029@archlute.fujixerox.co.jp> (message from
MURATA Makoto on Mon, 20 Sep 1999 14:38:25 +0900)
References: <199909200538.AA02029@archlute.fujixerox.co.jp>
Message-ID: <199909201453.JAA06080@bruno.techno.com>
[Murata, Makoto:]
> Just like the semistructured database, application programs should
> never rely on schemata. If they do, they would discriminate invalid
> documents, which are a lot more common in the WWW. Let' use
> schemata only for sanity-checking.
I can only conclude that, in your world view, reliable information
interchange is not (or should not be) the uppermost priority for the
development of W3C standards. I'd be astonished if the e-commerce
community, for example, went along with that idea!
-Steve
--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com http://www.techno.com ftp.techno.com
voice: +1 972 231 4098
fax +1 972 994 0087
pager (150 characters max): srn-page@techno.com
3615 Tanner Lane
Richardson, Texas 75082-2618 USA
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)
From jesmith at kaon.com Mon Sep 20 16:58:19 1999
From: jesmith at kaon.com (Joshua E. Smith)
Date: Mon Jun 7 17:15:19 2004
Subject: Binary-encoding of XML for communication
In-Reply-To: <01de01bf010a$be84d3e0$a60a1712@col.w3.org>
Message-ID: <3.0.1.32.19990920110037.008dac30@tiac.net>
I looked at the WAP spec, and the subsequent comments on this list and have
concluded:
1) Yeah, a binary spec for XML is a cool idea after all. If nothing else,
we can probably parse a binary rep faster than we can parse text.
2) The WAP spec does not seem to have any guiding principle for making the
transition from text to binary. In particular, tossing out comments with
the bathwater is a strange choice. Also, giving themselves a special set
of enumerations for DTDs is politically curious.
3) I wouldn't be surprised if a document encoded in their binary format
ended up *bigger* than a text XML doc rammed thru zlib (their use of octets
and 32-bit integers is going to lead to lots and lots of 0 bits). Is LZ
decompression a problem in embedded devices or something?
4) This spec is a lot closer to a network protocol than it is to the XML
spec, and, IMHO, it should be an IETF RFC, not a W3C Rec.
Anyone agree?
I propose we small-fry developers could do the following:
A) Decide *why* we want a binary XML spec, including rationale for that
decision
B) Produce an elegant spec and a reference implementation in C and java
C) Use IETF or a similarly open forum to promulgate it
I'm willing to step up to take the lead on this, although I'd happily back
off and let someone else take the reigns. I think this can help with both
download size and startup time issues with my company's product, so I'm
motivated to work on it.
With your permission, I'll take a crack at step A (using my best
approximation of the funny language of specs):
The binary XML format specification, hereafter referred to as XML-bin is
required to reduce the transmission size of XML documents, to speed
processing of those documents, and to reduce the size and complexity of XML
parser software. (For purposes of this specification, the existing XML
specification will be referred to as XML-text.)
The XML-bin format specification shall be a lossless encoding of a textual
XML document. That is, a document can be translated from XML-text to
XML-bin and back an arbitrary number of times, and no information content
will be lost. Information content, in this sense, excludes those
properties of the text which are defined as "insignificant white space" in
the XML specification [anything else we need to exclude here?].
The motivation for adjusting the machine representation of XML should be
expressed in the terms of computing machinery. Allowing this effort to
attempt to change the rules of what should be in an XML document (e.g., the
WAP attempt to banish comments), or to fix some bigger issues (e.g.,
allowing more expressive DTDs) would doubtless interfere with acceptance of
this specification as a standard.
How's that? The obvious (to me, anyway) way to implement that is to choose
a reasonable binary representation of a parse tree -- the way many
programming language compilers store data between their front-and and
back-end processes. Maybe a string table followed by a binary dump of a
heap (a tree stored in a vector, for those of you who never took a data
structures course), all rammed thru zlib to compress out common patterns.
But before we decide on the implementation, we need to reach consensus on
the motivation. Did I capture it?
-Joshua Smith
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)
From ann at webgeek.com Mon Sep 20 17:01:00 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:19 2004
Subject: an unfilled need
In-Reply-To: <00fd01bf0345$73f62080$97c566c3@unet.com>
Message-ID: <4.1.19990920105851.02699180@mail.webgeek.com>
>Rick Jeliffe wrote
>> I note Ann Navarro's call for "An unfulfilled need" earlier this month,
>on a subject I also have been calling for for 2 years+: the need for a
>mechanism to bind information to names: "definitions, semantics, and
>other data that may be necessary to complete their operations." This
>looks to me like a case of two non-commercial voices being lost to more
>important voices.
I don't in any arena (here, xml-plenary, and other water-cooler
discussions) feel that my suggestion was one of "two non-commercial voices
being lost to 'more important voices'".
The suggestion was indeed heard, digested, and discussed by individuals
who's work product impacts the idea. I have confidence that this area will
be explored.
I don't call that "lost", nor do I consider anyone else's "voice" more
important.
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From ann at webgeek.com Mon Sep 20 17:13:24 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:19 2004
Subject: an unfilled need
In-Reply-To: <4.1.19990920101807.02571400@mail.webgeek.com>
References: <00c701bf02dd$571ed690$42f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <4.1.19990920111258.026a2b20@mail.webgeek.com>
At 10:20 AM 9/20/99 -0400, Ann Navarro wrote:
>Not the goal, as has repeatedly been said, by more experts (of expert
>stature than myself),
That was a poorly executed attempt at saying "by people with greater
expertise than myself"
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From malliks at rocketmail.com Mon Sep 20 17:16:07 1999
From: malliks at rocketmail.com (Mallikarjuna Sangappa)
Date: Mon Jun 7 17:15:19 2004
Subject: Parsers for XML Schema
Message-ID: <19990920151830.9028.rocketmail@web4.rocketmail.com>
Hi,
I would like to know which parsers support XML Schema.
Has anybody experimented with XML Schema? Thanks in
advance.
Mallik
_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com
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)
From ann at webgeek.com Mon Sep 20 17:15:43 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:19 2004
Subject: Statement from HTML WG
In-Reply-To: <011901bf0378$a8db81e0$41f96d8c@NT.JELLIFFE.COM.AU>
Message-ID: <4.1.19990920111503.026a96d0@mail.webgeek.com>
It should be noted that Steven's indicated he's not subbed here, so if
anyone wants him to see your comments directly, please cc
Ann
At 10:58 PM 9/20/99 +0800, Rick Jelliffe wrote:
>
> From steven Thu Sep 16 15:02:06 1999
>
>>Using Namespaces
>>
>>The only place where the distinction between using one namespace and
>>using three is important is when including fragments of xhtml in
>>another document.
>
>A document processor can tell if a name has been used which it doesnt
>understand
>when it comes to that offending element. Otherwise we get the ludicrous
>position
>that a strict HTML processor will reject
>
>
> This is also available
> online .
>
>
>while accepting
>
>
> This is also available
> online .
>
>
>
>
>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/ 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)
>
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From ejfreed at infocanvas.com Mon Sep 20 17:18:27 1999
From: ejfreed at infocanvas.com (Erik James Freed)
Date: Mon Jun 7 17:15:19 2004
Subject: should FOP require JDK1.2.x?
In-Reply-To: <37E5B1DD.96DDE9B4@pacbell.net>
Message-ID:
I am sure you all realize this, but by going to 1.2 I believe that you leave
behind
all those who for one reason or another are using Microsoft Java. Not sure
if
this situation is a temporary one or not.
This does not constitute a recommendation even though I use MS Java for its
COM integration
features :-)
erik
> -----Original Message-----
> From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> David Brownell
> Sent: Sunday, September 19, 1999 9:03 PM
> To: XML-Dev Mailing list
> Subject: Re: should FOP require JDK1.2.x?
>
>
> James Tauber wrote:
> >
> > 3. Java 2D / Printing. I'd like Fop to be able to print and display on
> > screen directly without PDF as well as with and Java 2D /
> Printing would be
> > the obvious way to do this. The modular nature of Fop would enable me to
> > perhaps distribute a separate 1.2 application to do this and
> leave the core
> > as 1.1
>
> I certainly like the idea of direct Java2D output!
>
>
> > Incidently, from 0.10.0 I've been compiling with a 1.2.2
> compiler but only
> > using 1.1 libraries. Does anyone know if this will still cause
> problems for
> > people using 1.1. (ie should I go back to using a 1.1 compiler).
>
> I'd encourage using the 1.2 compiler; there were some code generation bugs
> with the 1.1 compiler that cause problems in various cases you
> really don't
> want to have to debug.
>
> - Dave
>
> 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)
>
>
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)
From david at megginson.com Mon Sep 20 17:44:33 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:19 2004
Subject: NOTICE: Megginson's Sprynet home page closing
Message-ID: <14310.22245.100989.711008@localhost.localdomain>
Due to growing Linux-hostility, I've switched to a different ISP for
when I'm travelling (I use a cable modem at home) and will be shutting
down my Sprynet home page at the end of the month. Most of the
information there is badly out-of-date anyway, but there are a couple
of documents that I thought people might still need, so I've moved
them to the following locations:
1. "Node Properties in Jade" (a short Groves overview)
Old location: http://home.sprynet.com/~dmeggins/grove.html
New location: http://www.megginson.com/docs/groves/grove.html
2. "Heart of Darkness" (HTML welcome page)
Old location: http://home.sprynet.com/~dmeggins/texts/darkness/index.html
New location: http://www.megginson.com/texts/darkness/index.html
3. "Heart of Darkness" (XML document entity)
Old location: http://home.sprynet.com/~dmeggins/texts/darkness/darkness.xml
New location: http://www.megginson.com/texts/darkness/darkness.xml
I know that the XML Heart of Darkness, in particular, is used as a
test document for XML software writers: it gives a good workout for
external entities, and shows up a persistent bug in many XML software
packages (which don't know how to distinguish a text declaration from
an XML declaration).
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From srn at techno.com Mon Sep 20 17:49:21 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun 7 17:15:19 2004
Subject: W3C's 'Moral Majesty'
In-Reply-To: <14310.15611.395555.890916@localhost.localdomain> (message from
David Megginson on Mon, 20 Sep 1999 09:56:11 -0400 (EDT))
References: <3.0.32.19990919115750.0120e420@pop.intergate.bc.ca>
<199909201328.IAA05813@bruno.techno.com> <14310.15611.395555.890916@localhost.localdomain>
Message-ID: <199909201546.KAA06155@bruno.techno.com>
[David Megginson:]
> Rather, Steve is arguing that universal names should not be an end in
> themselves -- and that's a very reasonable argument -- but that hardly
> disproves the claim that Namespace-qualified names are
> universally-distinguishable.
Thanks David. You're right. When Tim Bray said "universal", I
understood it in the general sense of the word, not in the sense of
"universally distinguishable." I do believe that namespaces make
names universally distinguishable, and, in fairness, that is all that
the namespace spec claims.
Tim Berners-Lee's universalistic claims for namespaces and RDF,
including his interpretation of the namespace spec, are what I take
issue with. He is creating expectations for reliable information
interchange on which he cannot deliver, but which are crowding real
solutions out of the public mindspace. When W3C does not deliver
something that works, and instead delivers something that does not
work, the official explanation is, "This is part of the solution, so
use it, trusting us when we tell you that rest of the solution is
coming Real Soon Now." It's very dominant-software-vendor-ish
behavior: when you don't have anything, occupy the market space with
promises, thus starving the competition for business.
My point is only that the W3C is a software-vendor-dominated group,
and it behaves as such. "By their fruits ye shall know them." That's
neither good nor bad; it's just a fact that should be borne in mind by
those who are thinking about looking to the W3C for technical
leadership. For some people, including the largest software vendors,
the W3C is a good choice. For many, it is best to regard the W3C as
just one leadership resource -- one that has much to offer. I believe
that some of its gifts are Trojan horses, and I can't be silent about
that, even if I have to play the role of Cassandra. "Look inside the
horse before taking the horse inside your city walls." That's all.
-Steve
--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com http://www.techno.com ftp.techno.com
voice: +1 972 231 4098
fax +1 972 994 0087
pager (150 characters max): srn-page@techno.com
3615 Tanner Lane
Richardson, Texas 75082-2618 USA
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)
From donpark at docuverse.com Mon Sep 20 17:55:59 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun 7 17:15:19 2004
Subject: Parsers for XML Schema
In-Reply-To: <19990920151830.9028.rocketmail@web4.rocketmail.com>
Message-ID: <000001bf0381$2addb2a0$8c1ecca1@w21tp>
>I would like to know which parsers support XML Schema.
>Has anybody experimented with XML Schema? Thanks in
>advance.
Only one I know of is IBM's XML4J. Look for the alpha version. I have not
experimented with XML Schema except to read the spec (too me a couple of
naps in between ;-).
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
From timm at channelpoint.com Mon Sep 20 17:58:01 1999
From: timm at channelpoint.com (Tim McCune)
Date: Mon Jun 7 17:15:20 2004
Subject: should FOP require JDK1.2.x?
Message-ID:
I think that the key phrase there is "too many people". You'll probably
offend those poor unfortunate folks who are using Mac's, Microsoft's JVM,
and other obscure environments, but with solid versions of 1.2 available on
Solaris, Linux, and Windows, that probably takes care of 90% of the people
who want to use FOP.
-----Original Message-----
From: James Tauber [mailto:jtauber@jtauber.com]
Sent: Saturday, September 18, 1999 7:21 PM
To: XML-Dev Mailing list
Subject: should FOP require JDK1.2.x?
I'd be interested in hearing people's views on the simple question: should
FOP (my XSL formatter/renderer) require JDK1.2.x? At present it works with
1.1.x.
What are other XML developers doing? Should I stick to 1.1.x compatibility?
Or can I require 1.2.x without offending too many people?
James
--
James Tauber / jtauber@jtauber.com / www.jtauber.com
Maintainer of : www.xmlinfo.com, www.xmlsoftware.com and www.schema.net
Ceci n'est pas une pipe
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)
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)
From davidc at nag.co.uk Mon Sep 20 18:00:35 1999
From: davidc at nag.co.uk (David Carlisle)
Date: Mon Jun 7 17:15:20 2004
Subject: Statement from HTML WG
Message-ID: <199909201559.QAA18918@nag.co.uk>
> The only place where the distinction between using one namespace and
> using three is important is when including fragments of xhtml in
> another document.
The distinction is important whenever one uses a namespace aware (rather
than XML 1.0) application. 3 namespaces makes querying into xhtml
documents with xpath (and thus with xslt) vastly more complicated.
The same would be true of any other XML namespace based application.
> However, in a fragment such as the following:
>
>
>
> This is also available
> online .
>
>
This really is the strangest claim. When importing an html p element
into the document type for notes, it is clear that (almost always)
you will want the paragraphs to contain inline elements from the
current document type as well as, or instead of, elements from html.
Thus the differences in the content model between a p in the 3 xhtml
DTD is _completely_ irrelevant, as the content model of this p will be
something else again. What is needed is
No `strict' no `1' version number This much is essential and
(possibly) no `x' either.
> The HTML WG opted for three namespaces on the grounds that one
> namespace makes one of the classes of use-case impossible, whereas
> three namespaces allows both, only making one of the classes harder to
> do.
Using one namespace does not make distinguishing between strict and
transitional impossible, it just means that you can't use the namespace
to do it, you have to use some more obvious system like having an
attribute that gives a url to the schema in use.
> However, the HTML WG is not bound irrevocably to three namespaces. We
> want XHTML to be a good XML citizen, and if the consensus of the XML
> community is that the 3-namespace use-cases are not important and can
> reasonably be ignored, we are willing to go with that consensus.
I am sure you will find that the consensus of the community is that
1 namespace should be used _and_ that the use-cases that need to
distinguish the DTD being used _are_ important (but that they should not
be distinguished by namespace)
Apart from this 1 v 3 argument there is still the worrying question not
really answered in the current drafts as to why xhtml is being specified
in a way incompatible with the namespace REC, which would make
and
equivalent, but the xhtml draft only acknowledges the validity of the
former?
David
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)
From ejfreed at infocanvas.com Mon Sep 20 18:24:12 1999
From: ejfreed at infocanvas.com (Erik James Freed)
Date: Mon Jun 7 17:15:20 2004
Subject: XPath and XQL
Message-ID:
Anyone have any insight into how these two technologies are likely to
cooexist/merge?
e
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)
From lucio.piccoli at one2one.co.uk Mon Sep 20 18:43:58 1999
From: lucio.piccoli at one2one.co.uk (LUCIO PICOLLI)
Date: Mon Jun 7 17:15:20 2004
Subject: Parsers for XML Schema
Message-ID: <3606eb56.200899@smtpgate1.ONE2ONE.CO.UK>
IBM have a XML4JEA that supports a in complete XML schema.
http://www.alphaworks.ibm.com/tech/xml4j
-lucio
> I would like to know which parsers support XML Schema.
> Has anybody experimented with XML Schema? Thanks in
> advance.
>
> Mallik
>
>
>
>
> _________________________________________________________
> DO YOU YAHOO!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> 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)
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)
From zepho at flashemail.com Mon Sep 20 19:12:58 1999
From: zepho at flashemail.com (Flash Gordon)
Date: Mon Jun 7 17:15:20 2004
Subject: PGML/VML Books
Message-ID: <-1869617572.937848173249.JavaMail.Administrator@harley>
Is there any good books on PGML or VML ? Please send your bookmarks and other resources too.
Thank you for your help.
Bala
Flash Gordon
____________________________________________________
get your permanent, free email at http://www.flashemail.com
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)
From gjenkinson at constellar.com Mon Sep 20 19:22:11 1999
From: gjenkinson at constellar.com (Gordon Jenkinson)
Date: Mon Jun 7 17:15:20 2004
Subject: (un)subscribe xml-dev
Message-ID: <316E18C624E9D211BF590060B068E29A127AF6@rwsexchange1.constellar.com>
(un)subscribe xml-dev
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)
From lisarein at finetuning.com Mon Sep 20 19:33:28 1999
From: lisarein at finetuning.com (Lisa Rein)
Date: Mon Jun 7 17:15:20 2004
Subject: PGML/VML Books
References: <-1869617572.937848173249.JavaMail.Administrator@harley>
Message-ID: <37E67298.1BA21FBA@finetuning.com>
No there aren't and who cares anyway?
I expected better from you Flash!
you should be following the SVG (Scalable Vector Graphics) standard if
you're interested in that sort of thing :-)
here's the latest working draft:
http://www.w3.org/TR/SVG/
here's the W3C SVG page at:
http://www.w3.org/Graphics/SVG/
here's the WDVL SVG page (which ain't half bad :-) :
http://www.wdvl.com/Authoring/Languages/XML/SVG/DoingIt/index.html
sincerely yours,
lisa rein
http://www.finetuning.com
Flash Gordon wrote:
>
> Is there any good books on PGML or VML ? Please send your bookmarks and other resources too.
> Thank you for your help.
> Bala
>
> Flash Gordon
>
> ____________________________________________________
> get your permanent, free email at http://www.flashemail.com
>
> 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)
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)
From prb at uic.edu Mon Sep 20 19:51:18 1999
From: prb at uic.edu (Paul R. Brown)
Date: Mon Jun 7 17:15:20 2004
Subject: (un)subscribe xml-dev
In-Reply-To: <316E18C624E9D211BF590060B068E29A127AF6@rwsexchange1.constellar.com>
Message-ID:
Perhaps the footer should read
To [un|]subscribe...
instead of
To (un)subscribe
> -----Original Message-----
> From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> Gordon Jenkinson
> Sent: Monday, September 20, 1999 12:28 PM
> To: xml-dev@ic.ac.uk
> Subject: (un)subscribe xml-dev
>
>
> (un)subscribe xml-dev
>
> 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)
>
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)
From simonstl at simonstl.com Mon Sep 20 19:57:04 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:20 2004
Subject: PGML/VML Books
In-Reply-To: <-1869617572.937848173249.JavaMail.Administrator@harley>
Message-ID: <199909201759.NAA13176@hesketh.net>
At 10:22 AM 9/20/99 -0700, Flash Gordon wrote:
>Is there any good books on PGML or VML ? Please send your bookmarks and
other resources too.
I don't think there are any books focusing on PGML or VML, but you may be
able to find XML books that provide some coverage. Chapter 18 of _Building
XML Applications_, which I wrote with Ethan Cerami, shows how to build a
viewer for a PGML subset. Chapter 18 of _Inside XML DTDs: Scientific and
Technical_, which I wrote with Robert Biggar, discusses PGML and VML with
some simple examples and discussions of what might come in SVG - at the
time, SVG was the future, just a requirements doc.
I can't recommend buying either of these books solely for PGML or VML
content, but they might give you at least a taste of what those tools can
do. (Read the chapters in a bookstore or library - I really don't mind.)
I know that Webmonkey (http://webmonkey.com) used to have some VML
tutorials, but they seem to have disappeared. Since VML got pretty deeply
into Office 2000, someone will probably cover it. Maybe one of the more
Microsoft-oriented XML books will provide a full tutorial, but so far as I
know, it hasn't appeared yet.
You might prefer to explore SVG, the W3C's _Scalable Vector Graphics_.
See http://www.hotwired.com/webmonkey/99/10/index3a.html for a fairly good
(though somewhat dated) intro. If it succeeds, everyone will support SVG,
from Microsoft (hopefully) and Adobe to IBM and Corel. The latest SVG
draft is at http://www.w3.org/TR/SVG.
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From czinkos at mail.matav.hu Mon Sep 20 20:32:24 1999
From: czinkos at mail.matav.hu (Zsolt Czinkos)
Date: Mon Jun 7 17:15:20 2004
Subject: XPath and XQL
References:
Message-ID: <37E67FDF.81A4295@mail.matav.hu>
Erik James Freed wrote:
>
> Anyone have any insight into how these two technologies are likely to
> cooexist/merge?
>
> e
Hello,
LotusXSL has sg like that (I haven't tried it, though).
See http://alphaworks.ibm.com
cz.
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)
From roddey at us.ibm.com Mon Sep 20 21:43:32 1999
From: roddey at us.ibm.com (roddey@us.ibm.com)
Date: Mon Jun 7 17:15:20 2004
Subject: We gotta break up these digests
Message-ID: <872567F2.006C8AC9.00@d53mta03h.boulder.ibm.com>
Is there any way we could break these digets up a bit? They were already so long
that I've given up doing any realistic reading of them, which is unfortunate but
necessary in order to get things done. Now I just skim them lightly. Now though,
they are getting long enough to bring my tools to their knees in one or another.
I unsubscribed from home because the last one sent IE5 off on a 4 minute freak
out that pretty much made the machine unusable. Of course this is probably bad
design on their part to assume that they can process mondo sized documents in
the GUI thread, but still that's what I've got to work with. Notes also has a
lot of trouble. Just marking some text is extremely piggy when the document gets
huge.
Am I the only one having these concerns? If so, feel free to ignore me :-)
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
roddey@us.ibm.com
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)
From cowan at locke.ccil.org Mon Sep 20 21:56:43 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun 7 17:15:20 2004
Subject: What XHTML should do with namespaces
In-Reply-To: <009a01bf006d$67f97460$1ff96d8c@NT.JELLIFFE.COM.AU> from "Rick Jelliffe" at Sep 17, 99 02:00:44 am
Message-ID: <199909202035.QAA00934@locke.ccil.org>
Rick Jelliffe scripsit:
> 1) There should be three namespaces:
> base
> slack
> frames
>
> 2) These namespace should be formally defined by means of a simple
> list in each case, so that every HTML 4 element is allocated to one only
> namespace each.
Doesn't work. Transitional doesn't just add new elements to Strict,
it adds new attributes for the old elements. Frameset differs because
it has different content models from Transitional.
--
John Cowan cowan@ccil.org
I am a member of a civilization. --David Brin
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)
From cowan at locke.ccil.org Mon Sep 20 22:13:29 1999
From: cowan at locke.ccil.org (John Cowan)
Date: Mon Jun 7 17:15:20 2004
Subject: Statement from HTML WG
In-Reply-To: <4.1.19990920091625.02546e70@mail.webgeek.com> from "Ann Navarro" at Sep 20, 99 09:17:37 am
Message-ID: <199909202051.QAA01669@locke.ccil.org>
Steven Pemberton scripsit:
> The only place where the distinction between using one namespace and
> using three is important is when including fragments of xhtml in
> another document. You can include a namespace at the top of a
> document, but there are other mechanisms available at that point for
> distinguishing the markup used, for the namespace not to be important.
But XHTML 1.0 does not support the reuse of its elements in documents
other than XHTML 1.0 documents. So what purpose does any namespace
at all serve?
> However, in a fragment such as the following:
>
>
>
> This is also available
> online .
>
>
>
> the namespace is the only mechanism available for identifying the
> vocabulary intended.
This is not XHTML 1.0. XHTML 1.0 claims to be a reformulation of
HTML 4.0 as XML, and HTML 4.0 does not support (even once you are past
the syntactic issues) being embedded in random XML documents.
--
John Cowan cowan@ccil.org
I am a member of a civilization. --David Brin
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)
From dave at userland.com Mon Sep 20 23:16:42 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun 7 17:15:20 2004
Subject: RFC: Attributes and XML-RPC
References: <37E67FDF.81A4295@mail.matav.hu>
Message-ID: <068301bf03ae$47be7440$1618ccce@pebbles>
Ever since discussions on XML-RPC started, the question of how to use
attributes, or if to use them at all, has been a constant source of debate.
Tim Lundeen of WebCrossing has pitched hard on the use of attributes, and I
have responded in a public mini-essay here:
http://www.xmlrpc.com/discuss/msgReader$506
Till now, I hadn't had a chance yet to write about this, so far all the
discussions have been less formal. If you have feedback or suggestions, they
would be welcome.
Dave
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)
From oren at capella.co.il Tue Sep 21 00:29:50 1999
From: oren at capella.co.il (Oren Ben-Kiki)
Date: Mon Jun 7 17:15:20 2004
Subject: Re xml-dev Digest V1 #348
References: <001101bf0301$aba79340$19acdccf@oemcomputer>
Message-ID: <060301bf03b6$80b01da0$4602a8c0@capella.co.il>
Frank Boumphrey wrote:
It seems as though you seriously suggest that the lack of documentation of
the technical process of creating the spec (specifically, the issues, the
alternatives, and the rationale for the adopted solutions) is "OK" since one
can simple E-mail some WG member and ask him to explain it for you. After
all, it works so well for you!
There is usually a requirements document, followed by several public working
drafts working drafts, followed by a propoaed recommendation, followed by a
recommendation.
Alas, a working draft/recommendation is not accompanied by a summary of the
internal W3C issue/alternatives/resolution documentation. As the XHTML case
demonstrates, this is problematic.
Public input is invited at every stage of this process.
The problem is not the ability to send recommendations to the WG, it is
having to second guess the reasons for the decisions it makes.
At any rate, I don't have the E-mail addresses of the XHTML WG members. I
can't officially get these addresses AFAIK.
The addresses of the editors are usually on the document.
True. But this address is not intended for asking questions about the
rationale for the draft - it is intended for submiting possible improvements
for it. I personally would not feel comfortable in using it in order to
obtain "rationale", though I'm certain the editors would provide it on
request. Every one of them I've been in contact with has been very helpfull.
However, this can't be the standard way to obtain it, because, as I've said:
Even if I could, it would not be
practical for them to answer my questions - because they'd be swamped with
the questions of every other interested reader of the draft.
I have never failed to get a response when I've written, and the times any
one has called me, I have always replied.
I fully appreciate the efforts that W3C members - editors included :-) - are
making to convey the rationale to the public. But I feel that answering
private E-mails should not be the prefered way to do so.
Obviously there is a reason why proper process
documentation is not being provided. The problem is that the simplest reason
is "to hide any shady politics between member companies".
I think you've been reading too many conspiracy novels!:>)
I didn't say I believed this to be the reason, I said it is the simplest
one. There are several advantages for providing a clear rationale:
- The quality of the drafts would increase. It turns out that having to
spell out the reasons for a decisions forces better decision making.
- The quality of outside input to the WG would improve. People won't be
rehashing old arguments - at least not as much.
- Developers would find it easier to accept decisions they disagree with.
The fact that the favored alternative was considered and found less
satisfactory for clearly specified reasons does wonders against the feeling
of being "left out of the process".
So the reason for _not_ providing a rationale has to be good enough to
override these three advantages. A pretty tall order, which explains why
there are "conspiracy theorists". I'm _not_ one - as I've repeatedly said,
I feel the W3C is doing a pretty good job overall. The ill feelings
manifested in this list towards the W3C can be pretty easily dispersed by a
bit of PR effort - and by releasing technical rationale documentation.
The w3c works by consensus!
The documentation that is not publically available is for the most part not
worth reading! Many of the internal mailing lists make this list look like
the embodiment of decorum and lucidity!
I didn't say anything about a general release of all internal documentation
and not even a release of the meeting protocols. I agree with you that this
would be pretty much useless. What I would like to see is some rationale
documentation as an integral part of each working draft and recommendation.
This would be _based_ on the existing internal documentation already
required by the W3C process.
Another reason is
"because it would harm the quality of the resulting recommendation" -
obviously absurd, or maybe "it would slow things down too much"
It's very difficult to get 16 people to agree, yet alone a whole mailing
list
Nobody said that the whole world should agree with every decision made by
the WG. As I've said above, a rationale is a very good way to make
developers accept reasonable decisions they don't agree with.
Share & Enjoy,
Oren Ben-Kiki
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)
From david-b at pacbell.net Tue Sep 21 00:24:23 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun 7 17:15:21 2004
Subject: Statement from HTML WG
References: <4.1.19990920091625.02546e70@mail.webgeek.com>
Message-ID: <37E6B48D.217920A1@pacbell.net>
> From: Steven Pemberton
> Subject: XHTML: One Namespace or Three?
>
> Executive summary: Namespaces are used by software to distinguish what
> is contained in a piece of markup. ...
Actually, that's the role assigned to DTDs. "What is contained" is a
content model style constraint. Namespaces are only used to disambiguate
the markup itself, as you said later -- "table" as in XHTML versus a kind
of furniture, "frame" as in XHTML versus door (or window...) construction.
> What are Namespaces
>
> ... according to the Namespace recommendation, Namespaces are used to
> disambiguate different vocabularies, without saying where those
> vocabularies come from. ...
Which says nothing about placing constraints on how those vocabularies
are used. DTDs address such constraints, and they aren't synonymous
with definitions of vocabularies.
This is shown by the HTML spec, which talks about "one language" and yet
has "three DTDs" used to provide three different kinds of constraint
about how its vocabulary is used. (Also by common usage -- "HTML" does
not generally care about such nuances.)
> History
>
> After publishing the draft we received two comments (though without
> technical argumentation) saying that there should only be one
> namespace.
Odd -- I knew of at least three, each with technical argumentation.
Those were highlighted on the plenary (back when I had regular access
to that sort of information). And I seem to recall that they were
not the only comments to that effect, but only the ones which seemed
most clearly expressed.
> Using Namespaces
>
> ... in a fragment such as the following:
>
>
>
> This is also available
> online .
>
>
>
> the namespace is the only mechanism available for identifying the
> vocabulary intended.
True. And DTDs are the only mechanism available for specifying any
content model restrictions that may be desired.
It has been made abundantly clear that developers expect schema mechanisms
to support content model restrictions when combining vocabularies ... and
to do so without depending on specific prefixes. Likewise, it is clear that
until such schema mechanisms exist, people WILL use DTDs for at least some
cases of vocabulary combination, by hardwiring prefixes. (Not all -- "some",
hence the desire to see progress on schemas.)
The point has also been raised that in the example above, the "p" element
would often need to contain inline elements from specialized vocabularies.
Using a namespace to identify a content model (instead of a separate DTD
or schema) effectively precludes vocabulary re-use through combination,
which is quite contrary to the goals I've understood for XML, namespaces,
or related technologies.
- Dave
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)
From Daniel.Veillard at w3.org Tue Sep 21 00:38:29 1999
From: Daniel.Veillard at w3.org (Daniel Veillard)
Date: Mon Jun 7 17:15:21 2004
Subject: W3C's 'Moral Majesty'
In-Reply-To: <199909201437.KAA02287@hesketh.net>
References: <199909191900.PAA32396@hesketh.net> <4.1.19990920100826.02570ac0@mail.webgeek.com> <199909201437.KAA02287@hesketh.net>
Message-ID: <19990920184043.B13296@w3.org>
> Open source in these senses remains poorly served by the W3C's process (and
> probably by the Open Group's process as well, from what I can gather on
> their site.)
I agree that software availability/testing is not the primary axis of W3C
process. We rely on members (and others) implementation when needed to
check whether a specification is implementable and has been successfully
implemented. Those are looked at when doing the Last Call and going to
Proposed Recommendation but agreed it's not as formal as within the
IETF process (2 different interoperable implementations for each features
in the specification). Though Working Groups may adopt such practices
(it had been done already).
So basically we don't focuse on software, but we do use in-home testbed
(Amaya, Jigsaw, Libwww ...) when needed, to test and "eat our own dog food"
as much as possible. This software is released under OpenSource compliant
licences and mechanism.
Check
http://www.w3.org/Status.html
and
http://dev.w3.org/
for a list of software and our public CVS base,
Daniel
--
Daniel.Veillard@w3.org | W3C, INRIA Rhone-Alpes | Today's Bookmarks :
Tel : +33 476 615 257 | 655, avenue de l'Europe | Linux, WWW, rpmfind,
Fax : +33 476 615 207 | 38330 Montbonnot FRANCE | rpm2html, XML,
http://www.w3.org/People/W3Cpeople.html#Veillard | badminton, and Kaffe.
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)
From david-b at pacbell.net Tue Sep 21 01:07:41 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun 7 17:15:21 2004
Subject: Another look at namespaces
References: <199909200538.AA02029@archlute.fujixerox.co.jp> <199909201453.JAA06080@bruno.techno.com>
Message-ID: <37E6BECB.F6F3938F@pacbell.net>
"Steven R. Newcomb" wrote:
>
> [Murata, Makoto:]
>
> > Just like the semistructured database, application programs should
> > never rely on schemata. If they do, they would discriminate invalid
> > documents, which are a lot more common in the WWW. Let' use
> > schemata only for sanity-checking.
>
> I can only conclude that, in your world view, reliable information
> interchange is not (or should not be) the uppermost priority for the
> development of W3C standards. I'd be astonished if the e-commerce
> community, for example, went along with that idea!
You're conflating reliable information interchange with schemas, I think.
Schemas, DTDs, and rules of all kinds are only aids to help achieve
goals ... and those goals can often be achieved without "excessive"
formalizing of those rules, as well as by use of more than one sort
of formalization (when formality is required). What would be wrong
with completely abstracting sanity checking? It's common practice.
I'd agree that other organizations may be better equipped to deal
with their domain-specific requirements for reliable interchange of
information. I'd really not want to see W3C create a world of square
pegs, given the wide variety of hole shapes (triangular, elliptical,
heptagonal, etc) in use, and the fact that many problems don't fit
well into the hole/peg class of design models! ;-)
- Dave
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)
From Marc.McDonald at Design-Intelligence.com Tue Sep 21 01:22:50 1999
From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com)
Date: Mon Jun 7 17:15:21 2004
Subject: Statement from HTML WG
Message-ID: <4454C011BDE5D211B6C800609776E540268307@master.design-intelligence.com>
Steve Pemberton wrote:
> Since we were getting different messages from the XML Community, we
> also asked the XML Plenary group to discuss the issue. This (long)
> discussion starts at
> [http://lists.w3.org/Archives/Member/w3c-xml-plenary/1999Jul/0017.html].
> (See the end of this document for some selections.) The result of these
> discussions seems to show that there isn't consensus on the issue,
> with people arguing quite strongly for both positions.
>
Nice to have a reference, but we non-w3C members can't reference the
document. So I have no description of these use cases that justify 3
namespaces. I got a password request on access. The only example given in
the mail is the including XHTML in XML documents which doesn't justify 3
namespaces at all.
> However, the HTML WG is not bound irrevocably to three namespaces. We
> want XHTML to be a good XML citizen, and if the consensus of the XML
> community is that the 3-namespace use-cases are not important and can
> reasonably be ignored, we are willing to go with that consensus.
>
Nice to hear this, which appears to be opposite of what had
previously been implied.
> Marc B. McDonald
> Principal Software Scientist
>
> Design Intelligence, Inc.
> 1111 Third Avenue, Suite 1500
> Seattle, WA 98101
> marc.mcdonald@design-intelligence.com
> Ph: 206.343-7797
> Fax: 206.343.7750
>
> http://www.design-intelligence.com
>
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)
From cbullard at hiwaay.net Tue Sep 21 01:46:00 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun 7 17:15:21 2004
Subject: W3C's 'Moral Majesty'
References: <3.0.32.19990919115750.0120e420@pop.intergate.bc.ca>
<199909201328.IAA05813@bruno.techno.com> <14310.15611.395555.890916@localhost.localdomain>
Message-ID: <37E6C6D8.38A2@hiwaay.net>
David Megginson wrote:
>
> Rather, Steve is arguing that universal names should not be an end in
> themselves -- and that's a very reasonable argument -- but that hardly
> disproves the claim that Namespace-qualified names are
> universally-distinguishable.
Umm.. they are universally distinguishable strings as far as I can tell
in
any system that uses and ensures the uniqueness of URIs.
A name names something.
Maybe I am just confused. I don't see what "the big deal is"
as my son says. The namespace spec is clear that it is only
a record of authority for the role of the namespace identifier
as a means to make a particular string unique. It clearly
says the members of a set of strings which can have a
namespace identifier, and it enables scope for members
of that set.
Beyond that, it's use as a URI would *appear* to indicate
to any average web user (the folks who see and http: on
any string and click on it), this is a pointer. So regardless
of linguistics or the record of authority, that is the expectation.
(AncientSGMLLore: Don't shock the Monkey. Looks like URI,
is a URI, Click. Monkey See Monkey Do.)
A name names something. What????? If we can't get that information,
or we have to code something that represents our vote on the matter,
or even just asserts our opinion because we get no vote, then
the situation is as Steve describes it. Even if there is no
vendor domination, it works precisely as if there were. Until
someone big enough with enough distribution votes or asserts
their opinion, there is no decision.
I say it points to the resource that is what the name names.
len
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)
From murata.makoto at fujixerox.co.jp Tue Sep 21 03:52:45 1999
From: murata.makoto at fujixerox.co.jp (MURATA Makoto)
Date: Mon Jun 7 17:15:21 2004
Subject: Another look at namespaces
Message-ID: <199909210154.AA02051@archlute.fujixerox.co.jp>
>> Just like the semistructured database, application programs should
>> never rely on schemata. If they do, they would discriminate invalid
>> documents, which are a lot more common in the WWW. Let' use
>> schemata only for sanity-checking.
>
>I can only conclude that, in your world view, reliable information
>interchange is not (or should not be) the uppermost priority for the
>development of W3C standards. I'd be astonished if the e-commerce
>community, for example, went along with that idea!
I am afraid that I have not made myself clear.
I am not saying that application programs rely on schemata when they
write application programs.
I am just saying no information in schemata should be leaked to
application programs at *RUN TIME*.
Makoto
Fuji Xerox Information Systems
Tel: +81-44-812-7230 Fax: +81-44-812-7231
E-mail: murata.makoto@fujixerox.co.jp
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)
From asalim at nest.stpt.soft.net Tue Sep 21 05:29:21 1999
From: asalim at nest.stpt.soft.net (AZEEM SALIM A)
Date: Mon Jun 7 17:15:21 2004
Subject: No subject
Message-ID: <41FFDF4384E9D111829C006094512CFC0123D5FF@PDC1>
(un)subscribe xml-dev
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)
From ebohlman at netcom.com Tue Sep 21 07:33:59 1999
From: ebohlman at netcom.com (Eric Bohlman)
Date: Mon Jun 7 17:15:21 2004
Subject: We gotta break up these digests
In-Reply-To: <872567F2.006C8AC9.00@d53mta03h.boulder.ibm.com>
Message-ID:
On Mon, 20 Sep 1999 roddey@us.ibm.com wrote:
> Is there any way we could break these digets up a bit? They were already so long
> that I've given up doing any realistic reading of them, which is unfortunate but
Though I don't subscribe to this list as a digest, I just started
subscribing to XSL-L as a digest, and there I'm running into the same
problems, only worse. The typical XSL-L digest is about 50K, for two
reasons:
1) Failure of participants to trim down the material they're quoting.
It's becoming increasingly common, apparently because of the way
browser-integrated mail clients and newsreaders work, for participants to
post their reply followed by a quote of the *entire* previous message. On
the comp.lang.perl.misc newsgroup, we call this "Jeopardy-style quoting"
(from the US TV game show where participants are given an answer and have
to come up with the question). The result is that a digest will often
contain an answer followed by the original question, and later in that
same issue another answer followed by the *same* original question, and
then a followup to one of the answers, followed by the answer, followed by
*yet another* copy of the original question! As a result, digests are
typically three times as long as they need to be.
2) The inclusion of duplicate text and HTML messages. If you're using a
browser-integrated newsreader, *turn this feature off* when posting to a
list! This isn't so much a problem on this list, presumably due to the
high technical sophistication of the participants, but it is a problem on
XML-L and XSL-L.
Some simple discipline in quoting is really the key to keeping digests
down to a usable length. Unless the original message is extremely short
(i.e. no more than one paragraph) there's almost *never* a reason to quote
the whole thing as an entire block; quote only those points that you're
specifically replying to, and only enough of them to provide context, and
intersperse your replies between the quotes. Use a notation like '[snip]'
(or '
examples.getStateName
41
xml:attr attribute marks the element as being an attribute of one of its
ancestor element. There is a constraint that you can not have to more than
one element that maps to same attribute. How to express this in schema is a
definite problem though.
A weird idea but seems very useful at first glance, more for DOM than SAX.
Best,
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
From ldodds at ingenta.com Tue Sep 21 12:56:39 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun 7 17:15:21 2004
Subject: Summaries please! (RE: We gotta break up these digests)
In-Reply-To: <872567F2.006C8AC9.00@d53mta03h.boulder.ibm.com>
Message-ID: <000501bf0420$354f0960$ab20268a@pc-lrd.bath.ac.uk>
> Is there any way we could break these digets up a bit?
Regular summaries on behalf of the participants involved in
some of the um, more heated and lengthy discussions would
be useful as well (perhaps these could go to a separate
list for those who want digests?).
I've completely lost track of this list lately because
of the sudden spike in traffic. I *know* I'm missing useful
stuff, I just haven't got the time to dig through all
the posts to find the jewels amongst all the pushing and
shoving.
I doubt anyone is going to offer to summarise the whole list,
but perhaps one or more participants from the major threads
could take a time out occasionally? Please?!
Cheers,
L.
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)
From asalim at nest.stpt.soft.net Tue Sep 21 13:04:22 1999
From: asalim at nest.stpt.soft.net (AZEEM SALIM A)
Date: Mon Jun 7 17:15:21 2004
Subject: (un)subscribe xml-dev
Message-ID: <41FFDF4384E9D111829C006094512CFC0123D7A0@PDC1>
(un)subscribe xml-dev
-----Original Message-----
From: Don Park [mailto:donpark@docuverse.com]
Sent: Tuesday, September 21, 1999 3:58 PM
To: 'Dave Winer'; xml-dev@ic.ac.uk
Subject: RE: Attributes and XML-RPC
Dave,
I recently had an idea on this problem but haven't had much time to form an
opinion about it. Anyway, here it is. Comments or flames are welcome.
The idea is to introduce a special attribute to mark elements which can be
attributes: xml:attr.
Here is an example of how it is used.
examples.getStateName
41
xml:attr attribute marks the element as being an attribute of one of its
ancestor element. There is a constraint that you can not have to more than
one element that maps to same attribute. How to express this in schema is a
definite problem though.
A weird idea but seems very useful at first glance, more for DOM than SAX.
Best,
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
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)
From simonstl at simonstl.com Tue Sep 21 14:20:38 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:21 2004
Subject: W3C and Open Source (was Re: W3C's 'Moral Majesty')
In-Reply-To: <19990920184043.B13296@w3.org>
References: <199909201437.KAA02287@hesketh.net>
<199909191900.PAA32396@hesketh.net>
<4.1.19990920100826.02570ac0@mail.webgeek.com>
<199909201437.KAA02287@hesketh.net>
Message-ID: <199909211223.IAA20237@hesketh.net>
At 06:40 PM 9/20/99 -0400, Daniel Veillard wrote:
>> Open source in these senses remains poorly served by the W3C's process (and
>> probably by the Open Group's process as well, from what I can gather on
>> their site.)
>
> I agree that software availability/testing is not the primary axis of W3C
>process.
Open source software is about a _lot_ more than "software
availability/testing" - it's providing serious competition to many of the
members of the W3C with 'real' software. Unfortunately, it's a competitor
that's pretty well locked out of the process, because of the cost, secrecy,
and structure of the W3C.
The original argument is here:
http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0935.html
>We rely on members (and others) implementation when needed to
>check whether a specification is implementable and has been successfully
>implemented. Those are looked at when doing the Last Call and going to
>Proposed Recommendation but agreed it's not as formal as within the
>IETF process (2 different interoperable implementations for each features
>in the specification). Though Working Groups may adopt such practices
>(it had been done already).
While I think a '2 different interoperable' rule might improve W3C
projects, that isn't what this argument is about. It's about the ways that
the W3C's consortium setup locks out open source projects until after the
ink is dry. While XML has benefited from open source projects, notably
Aelfred and Expat, those tended to be the work of individuals actually
participating on the WGs, not the work of larger groups (say, the Apache
group.)
> So basically we don't focuse on software, but we do use in-home testbed
>(Amaya, Jigsaw, Libwww ...) when needed, to test and "eat our own dog food"
>as much as possible. This software is released under OpenSource compliant
>licences and mechanism.
I like this stuff, certainly. It doesn't excuse the W3C for being
inhospitable to external open source projects, however.
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From srn at techno.com Tue Sep 21 15:40:36 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun 7 17:15:21 2004
Subject: Another look at namespaces
In-Reply-To: <37E6BECB.F6F3938F@pacbell.net> (message from David Brownell on
Mon, 20 Sep 1999 16:10:03 -0700)
References: <199909200538.AA02029@archlute.fujixerox.co.jp> <199909201453.JAA06080@bruno.techno.com> <37E6BECB.F6F3938F@pacbell.net>
Message-ID: <199909210419.XAA07391@bruno.techno.com>
[David Brownell:]
> You're conflating reliable information interchange with schemas, I
> think.
Perhaps. I confess that I don't understand how reliable (but
system-vendor-neutral) information interchange is possible without
insisting that the interchanged information conforms to some model.
If you're saying that I think that strict adherence to models is
essential for reliable, vendor-independent processing of interchanged
information, then you're exactly right: I do "conflate reliable
information interchange with schemas".
> Schemas, DTDs, and rules of all kinds are only aids to help achieve
> goals ... and those goals can often be achieved without "excessive"
> formalizing of those rules, as well as by use of more than one sort
> of formalization (when formality is required). What would be wrong
> with completely abstracting sanity checking? It's common practice.
I don't understand what you mean by "completely abstracting sanity
checking". Is (or is not) "sanity checking" validation against some
model? If it isn't, I'm completely baffled. If it is, are you saying
that the model should not be formalized, to protect machines from any
possibility that they will be used to perform the sanity check? Or
are you saying that there should be nothing rigorous about the model;
that "sanity" is something that only a human being can judge,
impressionistically, in the same manner as "beauty"?
> I'd really not want to see W3C create a world of square
> pegs, given the wide variety of hole shapes (triangular, elliptical,
> heptagonal, etc) in use, and the fact that many problems don't fit
> well into the hole/peg class of design models! ;-)
I agree with you that everyone should be able to make holes and pegs
in whatever shapes they want. The thing you seem to be objecting to
here is the idea that we should always be able to tell what the shape
of a hole is, so we can shape our pegs accordingly, and know in
advance whether the messages we're sending will be understandable in
precisely the ways we intend them to be understood by those who
receive them. In the case of any two people who want to interchange
information, I see no advantage in either of them being unable to tell
whether a message will be interpretable on arrival. Please explain
the nature of this advantage.
-Steve
--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com http://www.techno.com ftp.techno.com
voice: +1 972 231 4098
fax +1 972 994 0087
pager (150 characters max): srn-page@techno.com
3615 Tanner Lane
Richardson, Texas 75082-2618 USA
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)
From krebs at uni-koblenz.de Tue Sep 21 15:33:26 1999
From: krebs at uni-koblenz.de (Friedhelm Krebs)
Date: Mon Jun 7 17:15:21 2004
Subject: multidirectional links with XLINK
Message-ID: <37E789B2.F9E3393E@uni-koblenz.de>
Reading the X-Link-Specification I found the keyword
multidirectional-link, but I had no idea how to realize it with X-Link.
What?s the difference to, for instance, two uni-directional links, one
on each side?
Thank You
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)
From srn at techno.com Tue Sep 21 15:40:40 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun 7 17:15:22 2004
Subject: Another look at namespaces
In-Reply-To: <199909210154.AA02051@archlute.fujixerox.co.jp> (message from
MURATA Makoto on Tue, 21 Sep 1999 10:54:24 +0900)
References: <199909210154.AA02051@archlute.fujixerox.co.jp>
Message-ID: <199909210425.XAA07399@bruno.techno.com>
> I am just saying no information in schemata should be leaked to
> application programs at *RUN TIME*.
Oh, I didn't understand that! Thanks.
-Steve
--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com http://www.techno.com ftp.techno.com
voice: +1 972 231 4098
fax +1 972 994 0087
pager (150 characters max): srn-page@techno.com
3615 Tanner Lane
Richardson, Texas 75082-2618 USA
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)
From krebs at uni-koblenz.de Tue Sep 21 15:59:59 1999
From: krebs at uni-koblenz.de (Friedhelm Krebs)
Date: Mon Jun 7 17:15:22 2004
Subject: ID/IDREF-like Definitions in the Schema itself
Message-ID: <37E78FF3.F449A010@uni-koblenz.de>
ID and IDREF are attributes of an XML-document, to define associations
between elementes outside of the hierachie, but only of documents, this
means, of instances of a schema.
Is there any possibility to define an association like this in the
schema itself?
My problem is, I want to define, which elements of a document are needed
to calculate a sum, or to do any other operation. The result will be the
content of an element, and the operation will be called, while I create
the document instance.
If there?s a possibility, an application, who does the calculation,
could be universal, as I wouldn?t have to implement, where to get the
parameters.
A bad idea is to enumerate the element-names in a CDATA-Attribute, as
there is no possibility for validation.
Is there any other possibility?
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)
From lisarein at finetuning.com Tue Sep 21 16:33:15 1999
From: lisarein at finetuning.com (Lisa Rein)
Date: Mon Jun 7 17:15:22 2004
Subject: Summaries please! (RE: We gotta break up these digests)
References: <000501bf0420$354f0960$ab20268a@pc-lrd.bath.ac.uk>
Message-ID: <37E799C8.AA96731D@finetuning.com>
I think this is a ridiculous idea -- asking list participants to
re-summarize their lengthy threads -- as if they would or even could (if
they wanted to) take up even more of their own time to objectively and
succinctly cook this stuff down to a quick paragraph or two that might
be "useful" to people when they get around to reading it.
Maybe a plea to certain participants to please stop making the same
arguments over and over again, once they have already been beaten into
the ground (often by their own admission) would help with the current
traffic problem.
I will make that plea now.
lisa
Leigh Dodds wrote:
>
> > Is there any way we could break these digets up a bit?
>
> Regular summaries on behalf of the participants involved in
> some of the um, more heated and lengthy discussions would
> be useful as well (perhaps these could go to a separate
> list for those who want digests?).
>
> I've completely lost track of this list lately because
> of the sudden spike in traffic. I *know* I'm missing useful
> stuff, I just haven't got the time to dig through all
> the posts to find the jewels amongst all the pushing and
> shoving.
>
> I doubt anyone is going to offer to summarise the whole list,
> but perhaps one or more participants from the major threads
> could take a time out occasionally? Please?!
>
> Cheers,
>
> L.
>
> 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)
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)
From philipnye at freenet.co.uk Tue Sep 21 16:50:16 1999
From: philipnye at freenet.co.uk (Philip Nye)
Date: Mon Jun 7 17:15:22 2004
Subject: ID/IDREF-like Definitions in the Schema itself
Message-ID: <37E79E52.11D90B4F@freenet.co.uk>
Friedhelm Krebs wrote:
...
> My problem is, I want to define, which elements of a document are needed
> to calculate a sum, or to do any other operation. The result will be the
> content of an element, and the operation will be called, while I create
> the document instance.
...
> Is there any other possibility?
I'll have a go at this:
So far as I know, whilst proposed schemas allow much more complex
relationships to be expressed than a DTD, they are not up to expressing
this sort of constraint - "If element A takes a certain value or has
certain contents then element B over there must fit a particular model".
However, this is just the sort of thing which you can do very neatly
with XSLT - look for posts on "Crazy Idea" on this list in the last
couple of months for some leads.
Quoting from Rick Jelliffe:
> I have a note on "Using XSL as a Validation Language" at
> http://www.ascc.net/xml/en/utf-8/XSLvalidation.html also published in
> July Interchange magazine (ISUG).
Philip Nye
Engineering Arts UK
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)
From john.tigue at tigue.com Tue Sep 21 17:14:43 1999
From: john.tigue at tigue.com (John Tigue)
Date: Mon Jun 7 17:15:22 2004
Subject: RFC: Attributes and XML-RPC
Message-ID: <005901bf044c$da269350$788410d2@tigue.oz.net>
Winer wrote:
> You may have noticed that the XML-RPC spec says
> nothing about attributes, and none of the specified
> functionality uses attributes in any way.
>
> This is not an accident, there were many discussions about
> this, and I was always against using attributes because
> they couldn't expand in the future. I imagined that we
> would use an attribute for something and later would want
> to allow that to be a hierarchy, for it to contain
> sub-information, and there is no way to do that with
> attributes.
Perhaps my memory fails me but I clearly remember being in
a SOAP meeting at Microsoft where a very wrong headed gentleman
from Redmond (name withheld to protect the confused)
responding to my question "why no attributes". One high
profile XML guy from Microsoft who was present at the
meeting was taken aback by the decisions made. The first
gentleman expressed the opinion that attributes in general were
an unnecessary redundancy in the XML spec and he would have
nothing to do with them in SOAP.
As for "expand"-able attributes, an IDREF would suffice.
See XML1.0 at:
http://www.w3.org/TR/1998/REC-xml-19980210
/John
--
John Tigue
john.tigue@tigue.com
http://www.tigue.com
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)
From steven.livingstone at scotent.co.uk Tue Sep 21 17:35:03 1999
From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM)
Date: Mon Jun 7 17:15:22 2004
Subject: Attributes and XML-RPC
Message-ID: <8DCB90532FF7D211B34400805FD48853712372@SENMAIL3>
Not sure if I miss the point , but why not XDR + XSLT so that whether it was
marked as an element or attribute it wouldn't matter in the end?
This would also allow mapping between two differently structured, but
similar objects or classes.
Steven
> -----Original Message-----
> From: Dave Winer [SMTP:dave@userland.com]
> Sent: 20 September 1999 22:23
> To: xml-dev@ic.ac.uk
> Subject: RFC: Attributes and XML-RPC
>
> Ever since discussions on XML-RPC started, the question of how to use
> attributes, or if to use them at all, has been a constant source of
> debate.
> Tim Lundeen of WebCrossing has pitched hard on the use of attributes, and
> I
> have responded in a public mini-essay here:
>
> http://www.xmlrpc.com/discuss/msgReader$506
>
> Till now, I hadn't had a chance yet to write about this, so far all the
> discussions have been less formal. If you have feedback or suggestions,
> they
> would be welcome.
>
> Dave
>
>
> 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)
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)
From dave at userland.com Tue Sep 21 17:43:45 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun 7 17:15:22 2004
Subject: RFC: Attributes and XML-RPC
References: <005901bf044c$da269350$788410d2@tigue.oz.net>
Message-ID: <001901bf0448$f45571a0$1618ccce@pebbles>
I agree that attributes are an unfortunate and unnecessary redundancy in
XML. I was not that wrong-headed guy from Microsoft, but if I knew who it
was, I would agree with him. BTW, a very interesting discussion is happening
over on the XML-RPC DG. It's not an exact replay of the discussions we had
last year. Dave
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)
From tbray at textuality.com Tue Sep 21 18:05:15 1999
From: tbray at textuality.com (Tim Bray)
Date: Mon Jun 7 17:15:22 2004
Subject: RFC: Attributes and XML-RPC
Message-ID: <3.0.32.19990921090755.00b95a00@pop.intergate.bc.ca>
At 08:49 AM 9/21/99 -0700, Dave Winer wrote:
>I agree that attributes are an unfortunate and unnecessary redundancy in
>XML. I was not that wrong-headed guy from Microsoft, but if I knew who it
>was, I would agree with him. BTW, a very interesting discussion is happening
>over on the XML-RPC DG. It's not an exact replay of the discussions we had
>last year. Dave
There's a repeating pattern here. When I first discovered SGML (in
1987) I quickly decided that attributes were an unnecessary and superfluous
redundancy, and single-handedly transduced the 572 MB of the Oxford English
Dictionary text to reflect that viewpoint.
I've noticed this pattern in others besides myself and Dave. People who
come to generic markup with a lot of experience in technology don't see
why you need two different syntaxes for labeling information.
Years later, I got used to it. From the programmer's point of view, there's
no difference in the degree-of-difficulty of extracting info from elements
and attributes. And in the (large, important) subset of XML where the
information is created and handled directly by humans, I have observed
that people get a warm fuzzy glow from attributes and find XML more readable
when some stuff is in attributes. So... why struggle? -Tim
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)
From simonstl at simonstl.com Tue Sep 21 18:15:46 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:22 2004
Subject: Summaries please! (RE: We gotta break up these digests)
In-Reply-To: <000501bf0420$354f0960$ab20268a@pc-lrd.bath.ac.uk>
References: <872567F2.006C8AC9.00@d53mta03h.boulder.ibm.com>
Message-ID: <199909211615.MAA32098@hesketh.net>
At 11:58 AM 9/21/99 +0100, Leigh Dodds wrote:
>> Is there any way we could break these digets up a bit?
>
>Regular summaries on behalf of the participants involved in
>some of the um, more heated and lengthy discussions would
>be useful as well (perhaps these could go to a separate
>list for those who want digests?).
>
>I've completely lost track of this list lately because
>of the sudden spike in traffic. I *know* I'm missing useful
>stuff, I just haven't got the time to dig through all
>the posts to find the jewels amongst all the pushing and
>shoving.
>
>I doubt anyone is going to offer to summarise the whole list,
>but perhaps one or more participants from the major threads
>could take a time out occasionally? Please?!
Writing summaries might well turn into essays, given the scope of the
discussion on this list. I'm not sure people who find ten minutes five
times a day to churn out email could spend fifty consecutive minutes
dedicated to summaries. It's a good idea, though. Might even lead to some
useful books!
I really like the Slashdot approach, in which moderators annotate the
discussion, assigning points to commentators who regularly produce jewels
and letting readers filter out the Anonymous Cowards if they like by
setting a threshold. They also have the advantage of a more threaded
discussion, with separate forums for each topic, which makes it a lot
easier to get to just the information you want.
About two years ago, someone (Peter Murray-Rust?) posted an 'XML-dev
Jewels' page. That page was enormously helpful to me in figuring out a lot
of what was going on with XML, and getting started. It was just some key
messages from the archive, but they were great! I'd love to see more
resources like that, where someone could take the time to look over the
list and find its brightest patches. Even a simple list of 'bright
patches' with links to the archives would help a lot of folks. Similarly,
more third-party reporting, by people who can survive the archives (CNET
did) might make it easier for newcomers to figure out just what everyone's
talking about. Unfortunately, I don't know anyone who has the time, money,
and patience to do that on a regular basis.
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From simonstl at simonstl.com Tue Sep 21 18:19:27 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:22 2004
Subject: RFC: Attributes and XML-RPC
In-Reply-To: <001901bf0448$f45571a0$1618ccce@pebbles>
References: <005901bf044c$da269350$788410d2@tigue.oz.net>
Message-ID: <199909211621.MAA32402@hesketh.net>
At 08:49 AM 9/21/99 -0700, Dave Winer wrote:
>I agree that attributes are an unfortunate and unnecessary redundancy in
>XML. I was not that wrong-headed guy from Microsoft, but if I knew who it
>was, I would agree with him. BTW, a very interesting discussion is happening
>over on the XML-RPC DG. It's not an exact replay of the discussions we had
>last year. Dave
XML-RPC's simplicity is remarkable, and it's made it much easier to explain
to people, I've found. I don't know if lack of attributes is precisely
why, but the approach overall seems sound.
It'd be nice to find a way to exchange leaf elements and attributes without
breaking parser and validator expectations - that might get us out of the
recurring elements vs. attributes discussions. I'm not sure it would
address everything in XML-RPC, notably the way it does data typing with
nested elements, but it might help mellow this eternal and very basic
question.
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From david-b at pacbell.net Tue Sep 21 18:22:23 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun 7 17:15:22 2004
Subject: Another look at namespaces
References: <199909200538.AA02029@archlute.fujixerox.co.jp> <199909201453.JAA06080@bruno.techno.com> <37E6BECB.F6F3938F@pacbell.net> <199909210419.XAA07391@bruno.techno.com>
Message-ID: <37E7B13E.E0AC2E3E@pacbell.net>
"Steven R. Newcomb" wrote:
>
> [David Brownell:]
>
> > You're conflating reliable information interchange with schemas, I
> > think.
>
> Perhaps. I confess that I don't understand how reliable (but
> system-vendor-neutral) information interchange is possible without
> insisting that the interchanged information conforms to some model.
... that model doesn't need to be "schemas". Which I've observed seem
to be regularly invoked as the Silver Bullet that solves all problems.
> > Schemas, DTDs, and rules of all kinds are only aids to help achieve
> > goals ... and those goals can often be achieved without "excessive"
> > formalizing of those rules, as well as by use of more than one sort
> > of formalization (when formality is required). What would be wrong
> > with completely abstracting sanity checking? It's common practice.
>
> I don't understand what you mean by "completely abstracting sanity
> checking". Is (or is not) "sanity checking" validation against some
> model?
Sanity checking can be dealt with in a variety of locations. For three
examples: when a message is received; when it's generated; when the code
to generate it is designed.
Clearly different systems have different requirements there. Some systems
can't trust their messaging partners to generate correct data. Some have
more control, and strong enough design practice that they can "abstract
sanity checking" out of the runtime environment completely.
> The thing you seem to be objecting to
> here is the idea that we should always be able to tell what the shape
> of a hole is, so we can shape our pegs accordingly, and know in
> advance whether the messages we're sending will be understandable in
> precisely the ways we intend them to be understood by those who
> receive them.
Not at all. I'm just saying there are different ways to discover
the shape of the hole (as it were :-) and having the document declare
such things is far from the only way.
You can look at this from the communications-theoretic point of view
if you like: information that's already known doesn't need to be
redundantly encoded in each message. Leads to improved efficiency in
data transmission as well as in data processing. That knowledge is an
attribute of the overall communication, NOT just individual messages.
- Dave
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)
From ken at bitsko.slc.ut.us Tue Sep 21 18:29:19 1999
From: ken at bitsko.slc.ut.us (Ken MacLeod)
Date: Mon Jun 7 17:15:22 2004
Subject: Summaries please! (RE: We gotta break up these digests)
In-Reply-To: Lisa Rein's message of "Tue, 21 Sep 1999 07:44:24 -0700"
References: <000501bf0420$354f0960$ab20268a@pc-lrd.bath.ac.uk> <37E799C8.AA96731D@finetuning.com>
Message-ID:
Lisa Rein writes:
> I think this is a ridiculous idea -- asking list participants to
> re-summarize their lengthy threads -- as if they would or even could
> (if they wanted to) take up even more of their own time to
> objectively and succinctly cook this stuff down to a quick paragraph
> or two that might be "useful" to people when they get around to
> reading it.
I agree that it's asking too much for participants to summarize their
own lengthy threads, but it's something that someone else could do if
they had the time. Another person suggested a weekly summary posting,
similar to the one used on the Linux Kernel mailing list. An idea I
like is to use a brainstorming or decision-making tool to summarize
different points made, and link them to each other. One such
technique that is common are ``Mind Maps'' where you write the main
topic in the center of a piece of paper or whiteboard and then write
subtopics sourrounding the main topic, and further detailing out from
there. I know there is commercial software for tools like this, but
I'm not aware of many freely available ones.
Being the XML list and all, I started an XML DTD for organizing a
MindMap (as an outline in the first draft, it could be extended for 2D
or deeper linking). There's probably a few more hours of work needed,
including a stylesheet that can pull content from email messages, and
then someone needs to actually maintain topic pages. The main idea is
that the moderator(s) pull verbatim comments from the participants, or
the moderator condenses or paraphrases the content, and organizes it
into subtopics (threads). Since the moderator does not control the
information source itself (the mailing list) it is highly
self-regulating. Here's the draft DTD:
-------- mindmap-model-1.dtd --------
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)
From DuCharmR at moodys.com Tue Sep 21 18:33:54 1999
From: DuCharmR at moodys.com (DuCharme, Robert)
Date: Mon Jun 7 17:15:22 2004
Subject: Parsers for XML Schema
Message-ID: <01BA10F0CD20D3119B2400805FD40F9F277DF3@MDYNYCMSX1>
>IBM have a XML4JEA that supports a in complete XML schema.
>http://www.alphaworks.ibm.com/tech/xml4j
More details: According to Ted Leung of the IBM's Technology Group, writing
on the XML4Java discussion group at
http://www.alphaworks.ibm.com/aw.nsf/discussion?ReadForm&/forum/xmlforjava.n
sf/discussion?createdocument, "the current EA drop only supports
a subset of schema that is equivalent to DTDs. The next drop is going to
have datatype support, but probaby won't have archetype support."
Even more details: see the reassume file included with the release.
Bob DuCharme www.snee.com/bob see www.snee.com/bob/xmlann for "XML:
The Annotated Specification" from Prentice Hall.
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)
From david-b at pacbell.net Tue Sep 21 18:35:12 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun 7 17:15:22 2004
Subject: an unfilled need
References: <00fd01bf0345$73f62080$97c566c3@unet.com>
Message-ID: <37E7B439.5EC26457@pacbell.net>
Martin Bryan wrote:
>
> One of the techniques the XML/EDI community have been propounding
vs proposing? I'd be curious whether alternative approaches have been
examined, or what alternative techniques were discussed within the scope
of this particular approach.
> is the use
> of namespaced attributes to point to semantic specifications using the XLink
> mechanism or an application specific mechanism. Basically the namespace of
> the attribute points to the rules for interpreting the attribute value and
> the value of the attribute points to the definition of the semantics that
> are to be applied to the element.
This doesn't require actually trying to fetch information identified by a
URI. But it also leaves open the question of which level(s) of semantics
are tied to the namespaces in question.
- Dave
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)
From david-b at pacbell.net Tue Sep 21 18:38:28 1999
From: david-b at pacbell.net (David Brownell)
Date: Mon Jun 7 17:15:22 2004
Subject: RFC: Attributes and XML-RPC
References: <3.0.32.19990921090755.00b95a00@pop.intergate.bc.ca>
Message-ID: <37E7B4F9.DBC927FD@pacbell.net>
Tim Bray wrote:
>
> From the programmer's point of view, there's
> no difference in the degree-of-difficulty of extracting info from elements
> and attributes. And in the (large, important) subset of XML where the
> information is created and handled directly by humans, I have observed
> that people get a warm fuzzy glow from attributes and find XML more readable
> when some stuff is in attributes. So... why struggle? -Tim
Heck, if folk want XML without attributes, then I'd as soon just use
LISP S-Expresssions ... and since folk seem to have chosen not to go
that route, I'd say stick with the attributes! ;-)
- Dave
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)
From dave at userland.com Tue Sep 21 18:46:37 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun 7 17:15:23 2004
Subject: RFC: Attributes and XML-RPC
References: <005901bf044c$da269350$788410d2@tigue.oz.net> <199909211621.MAA32402@hesketh.net>
Message-ID: <003e01bf0451$86297830$1618ccce@pebbles>
> XML-RPC's simplicity is remarkable, and it's made it much easier to
explain
> to people, I've found. I don't know if lack of attributes is precisely
> why, but the approach overall seems sound.
Simon, thanks! Simplicity was *the* goal for XML-RPC, I believe it's the
result of leaving out things that we felt an HTML coder would find
confusing. No namespaces, no DTDs, no attributes. I think this way of doing
things has a place, esp since SOAP is so fully conformant with the latest
stuff from W3C. One method for full conformance, one method for
transparency.
I don't know which approach is going to gain traction, or if they both will.
There are SOAP implementations coming online very quickly, and there already
are a bunch of implementations of XML-RPC. I think that SOAP defines a good
upperbound for XML-RPC. I'm glad it's there. It's also great to Microsoft
pushing this stuff too!
Anyway, about attributes, I'd like to save them for something super-powerful
when we understand how this stuff is being deployed. To me, it feels like a
dollar in the bank, that when the technology matures, we have a dividend we
can use somewhere down the pike.
Also, the discussion on the XML-RPC DG is centered around language-specific
hinting. What if you want to hint two languages, not one? What if each
language requires a set of configuration info? What if one language requires
a hierarchy of configuration info? (That's not hard to imagine, not at all.)
Attributes are for wispy little very optional things, if they are for
anything at all. I see that there's lots of room for deepening s for
example. The hierarchy in XML-RPC is so meticulously hierarchic so that we
could hang stuff off those trees in the future. This goes back to
discussions I had with Mohsen Al-Ghosein at Microsoft in March 1998. Once he
explained it to me I said YES, that's very cool, let's do it that way.
Now we're at the crossroads he imagined, and we've got some people telling
us to hurry up and there's no way I want to do that. That's why I brought
the issue over here, because people like Simon and Tim and Don Park are here
(and Tim Berners-Lee!), and you guys have been dealing with much more
complex stuff in arrangements of tagged text than we have. I think you
should have a crack at this and help us make the decisions. XML-RPC can
belong to XML-DEV as much as it belongs to anyone. But I really want to keep
its simplicity as the prime goal. Maybe this is a time to do a little work
outside the W3C, sort of a skunkworks thing, let's see what kind of barn we
can raise.
Dave
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)
From dave at userland.com Tue Sep 21 18:48:06 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun 7 17:15:23 2004
Subject: Summaries please! (RE: We gotta break up these digests)
References: <000501bf0420$354f0960$ab20268a@pc-lrd.bath.ac.uk> <37E799C8.AA96731D@finetuning.com>
Message-ID: <004401bf0451$f36e7df0$1618ccce@pebbles>
It's really simple, XML-DEV needs a weblog.
UserLand would be happy to host and provide browser-based editorial tools if
someone wants to lead. (The tools even use XML!)
I've already been pointing to selective messages from XML-DEV on Scripting
News, esp ones from Tim Bray about big hairy servers.
It would be great if someone could point to all the major postings on this
list from the web on a daily basis.
Dave
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)
From fewayne at facstaff.wisc.edu Tue Sep 21 19:01:13 1999
From: fewayne at facstaff.wisc.edu (Rick Wayne)
Date: Mon Jun 7 17:15:23 2004
Subject: newbie-ish DTD question: am i asking too much of XML, or of my brain?
Message-ID: <37E7BB1B.CCD4B158@facstaff.wisc.edu>
hi all,
i have an astoundingly simple document format that i want to define via
a DTD, and can't get the parsers to let me do it. so far i've looked in
_the_XML_companion_, _the_XML_black_book_, and perused the spec. my
ignorance still throbs mightily.
in english:
i want my documents to consist of a "model" element. a model can
contain "topics" and "links", any number, in any order. in turn, topics
can contain topics and links, in any number, in any order. i can
tighten up the rules a little if need be -- for instance, requiring that
models contain at least one topic. but because these represent
mathematical operations, i can't just require that the topics come first
and the links follow (e.g., .
in (attempted) XML, with ATTLIST tags removed:
all non-profane feedback gratefully accepted.
thanks for taking the time to have a look. if you wish to respond via
private email instead of replicating to the list, that's dandy-fino with
me. i doubt this problem is sufficiently generic to interest everyone.
rw
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)
From DuCharmR at moodys.com Tue Sep 21 19:01:35 1999
From: DuCharmR at moodys.com (DuCharme, Robert)
Date: Mon Jun 7 17:15:23 2004
Subject: multidirectional links with XLINK
Message-ID: <01BA10F0CD20D3119B2400805FD40F9F277DF5@MDYNYCMSX1>
>Reading the X-Link-Specification I found the keyword
>multidirectional-link, but I had no idea how to realize it with X-Link.
>What?s the difference to, for instance, two uni-directional links, one
>on each side?
(I'll give it a shot; all corrections welcome.)
XLink lets you declare linking elements that have the job of defining links
(that is, identifying relationships) between resources. Let's say I declare
an element type called myLink that I'll use to link pairs of web pages
having a certain relationship. Once a given myLink element defines a
relationship between http://foo.com/a.html and http://bar.com/b.html, that
link may be implemented in such a way that someone at either end of the link
can travel to the other link, unless I used XLink's arc feature to restrict
such travel in myLink links. With no use of the arc feature, it's one single
myLink linking element defining a multidirectional link.
Because you can't do this in HTML, you would implement the same idea with
two , one in http://foo.com/a.html and one in
http://bar.com/b.html, and each pointing at the other. It may look the same
to the end user following the links, but two uni-directional A elements were
necessary to code it instead of a single myLink element.
By "realize," I guess you mean "implement." Just as the XML spec tells how
you might define an EMPHASIS element type but doesn't tell you how to
implement your emphasis (e.g. when converting to HTML, you might use Perl to
convert an EMPHASIS element to a B element), XLink doesn't tell you about
implementation either. (Well, it drops hints here and there, and I look
forward to implementers picking up on these hints, but they're waiting for
it to reach Recommendation status.) Instead, it tells you how to define and
encode relationships.
For now, the implementation of such a myLink link element could mean writing
out as many elements as are necessary, if you have
write access to the linked resources, or reading the pages in and inserting
the links in a copy or...whatever. Like I said, I look forward to
implementations that let us really have fun with these cool XLink features.
Bob DuCharme www.snee.com/bob see www.snee.com/bob/xmlann for "XML:
The Annotated Specification" from Prentice Hall.
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)
From donpark at docuverse.com Tue Sep 21 19:08:19 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun 7 17:15:23 2004
Subject: RFC: Attributes and XML-RPC
In-Reply-To: <199909211621.MAA32402@hesketh.net>
Message-ID: <000301bf0454$6d5defe0$8c1ecca1@w21tp>
It is true that attributes are redundant in a sense but they are far from
useless.
Its unobtrusive nature helps solve problems like XML Namespace. As Tim
mentioned, it does enhance readability. DTD is a lot more friendly to
attributes. With attributes, you can enforce 'just-once' constraint without
schema. XHTML would look awefully funny without attributes. The list goes
on and on.
Redundancy seems like a waste until one ends up between a rock and a hard
place.
Best,
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
From pete at clearlyonline.com Tue Sep 21 19:33:44 1999
From: pete at clearlyonline.com (Pete Beazley)
Date: Mon Jun 7 17:15:23 2004
Subject: newbie-ish DTD question: am i asking too much of XML, or of my brain?
In-Reply-To: <37E7BB1B.CCD4B158@facstaff.wisc.edu>
Message-ID: <001c01bf0457$cbc03360$0100a8c0@clearlyo2>
>
>
>
>
You need to separate the optional content with the OR connector, | , and
define some sort of content model for link.
Try this:
]>
Pete
--------
Pete Beazley - mailto:pete@clearlyonline.com
ClearlyOnline, Inc.
XML-based Web Sites & XML services
http://www.clearlyonline.com
1-724-942-1912 1-724-941-3698 fax
PGP public key - mailto:pgp.pete@clearlyonline.com
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)
From rbourret at ito.tu-darmstadt.de Tue Sep 21 19:39:51 1999
From: rbourret at ito.tu-darmstadt.de (Ronald Bourret)
Date: Mon Jun 7 17:15:23 2004
Subject: newbie-ish DTD question: am i asking too much of XML, or of my brain?
Message-ID: <01BF0469.A754E860@grappa.ito.tu-darmstadt.de>
Rick Wayne wrote:
> i want my documents to consist of a "model" element. a model can
> contain "topics" and "links", any number, in any order. in turn, topics
> can contain topics and links, in any number, in any order.
>
> in (attempted) XML, with ATTLIST tags removed:
>
>
>
>
>
Very close, but no cigar. In a content model with multiple entries, the
entries must be separated by a pipe symbol (|) (for choices) or a comma
(for sequences). However, just putting in one of these won't give you what
you want. For example:
means you can have either a bunch of topics or a bunch of links. Instead,
what you need to do is put the zero-or-more operator (*) on the content
group as a whole and a pipe between:
Furthermore, you need to declare a content model for the link element, such
as PCDATA (contains text) or EMPTY (contains nothing). For example:
--or--
Finally, you need to put your entire DTD in the internal subset (inside the
DOCTYPE statement) or in an external DTD. For example, here's your DTD in
the internal subset:
]>
...
And here's your DTD in an external DTD.
Assuming the external DTD file was named model.dtd and that file was in the
same directory as your XML document, you could reference it from a DOCTYPE
statement as follows:
...
-- Ron Bourret
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)
From DuCharmR at moodys.com Tue Sep 21 19:54:26 1999
From: DuCharmR at moodys.com (DuCharme, Robert)
Date: Mon Jun 7 17:15:23 2004
Subject: Parsers for XML Schema
Message-ID: <01BA10F0CD20D3119B2400805FD40F9F277DF6@MDYNYCMSX1>
>Even more details: see the reassume file included with the release.
Excuse me, that's "readme" file. (I will now add "readme" to my spellchecker
so that this doesn't happen again. I didn't know that "reassume" was even a
word.)
Bob
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)
From ejfreed at infocanvas.com Tue Sep 21 20:01:17 1999
From: ejfreed at infocanvas.com (Erik James Freed)
Date: Mon Jun 7 17:15:23 2004
Subject: RFC: Attributes and XML-RPC
In-Reply-To: <37E7B4F9.DBC927FD@pacbell.net>
Message-ID:
My thinking is that it is considered harmful to have two ways of doing
such semantically equivalent things, because this can easily lead to more
complicated implementations
and more complicated interfaces than is optimal. This rule of course can be
immediately broken if there is some truly useful distinction between the two
(they are not truely equivalent). The case
Tim is making for breaking this rule is one of readability e.g. that
attributes are more readable for certain features. Presumably this
readability advantage would diminish and reverse where attributes are long
enough to really want to be on multiple lines. So you have a feature where
the lenght of the string representing the value determines an implementation
change (kind of fugly as data modeling goes). I can see either side, but I
think that
readability is a troublingly subjective metric. Another argument is that
this seemingly small semantic aliasing may cause more problems in the future
as new features are added. Note the effect on query languages for instance.
God knows they need all the help they can get to limit complexity.
I would conclude that attributes were a truly unfortunate decision, and we
will live to regret it more in the future, but does the impact of this
decision have enough of an force to reverse a long standing language
feature? I kind of doubt it, I bet that there is now enough cultural
momentum to prevent that.
erik
> -----Original Message-----
> From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> David Brownell
> Sent: Tuesday, September 21, 1999 9:40 AM
> To: xml-dev@ic.ac.uk
> Subject: Re: RFC: Attributes and XML-RPC
>
>
> Tim Bray wrote:
> >
> > From the programmer's point of view, there's
> > no difference in the degree-of-difficulty of extracting info
> from elements
> > and attributes. And in the (large, important) subset of XML where the
> > information is created and handled directly by humans, I have observed
> > that people get a warm fuzzy glow from attributes and find XML
> more readable
> > when some stuff is in attributes. So... why struggle? -Tim
>
> Heck, if folk want XML without attributes, then I'd as soon just use
> LISP S-Expresssions ... and since folk seem to have chosen not to go
> that route, I'd say stick with the attributes! ;-)
>
> - Dave
>
> 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)
>
>
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)
From jmg at trivida.com Tue Sep 21 20:07:16 1999
From: jmg at trivida.com (Jeff Greif)
Date: Mon Jun 7 17:15:23 2004
Subject: Attributes vs. text content (Was Re: RFC: Attributes and XML-RPC)
References: <3.0.32.19990921090755.00b95a00@pop.intergate.bc.ca>
Message-ID: <028501bf045c$1de766f0$a24630d1@trivida.com>
For certain kinds of applications, I find the opposite style -- attributes
only and no PCDATA -- works best. One such use of XML was to organize a
configuration file for a call-center simulator. This plays back records of
call-center activity through a learning engine which rapidly figures out how
to predict with decent accuracy what the current (support or sales) call is
going to be about, and what the same person will probably call in with in
the future. The simulator's purpose was to enable the computation of how
many calls could be avoided or shortened by proactive behavior on the part
of the support agent when the call came in.
The XML file contained information about where to get the data, how it was
mapped into the learning engine, and where the database for output
information was found, as well as certain parameters that governed the
behavior of the simulator, such as how much feedback the agents would get
about whether the predictions were right. The DTD for this XML file
specified a raft of elements and attributes, but no PCDATA. It was
extremely convenient to be able to easily denote which attributes needed to
be present, to provide default values, insist on values from an enumerated
set (thus avoiding misspellings). We used a validating parser (IBM's), and
sucked the configuration out of the DOM into application-specific data
structures. The parser threw out invalid configuration information that
would have complicated the code significantly to detect, and supplied the
various default values. Basically, the configuration-reading code needed no
error-handling beyond passing on any complaints from the XML parser.
Erroneous information could still be provided that would cause the database
queries to fail, but database failure had to be handled anyway.
The users would come to me with almost any kind of problem, including
forgetting to start the learning server, but after I gave them one simple
and one more complex sample configuration file to cut and paste from, they
were able to download a database of calls in random format from some
prospective customer, and prepare a configuration file that worked after a
few iterations (usually not involving me). The configuration reading code
essentially worked the first time and needed few changes as the system
evolved. Structuring with only elements and attributes and using a
validating parser were important factors in this.
Anyone interested in the DTD or a sample config file can look at
http://www1.trivida.com/public/greif/CallAvoidanceConfig.dtd and
http://www1.trivida.com/public/greif/BlahBlahSmallConfig.xml
Jeff
----- Original Message -----
From: Tim Bray
To:
Sent: Tuesday, September 21, 1999 9:08 AM
Subject: Re: RFC: Attributes and XML-RPC
...
> There's a repeating pattern here. When I first discovered SGML (in
> 1987) I quickly decided that attributes were an unnecessary and
superfluous
> redundancy...
>
> I've noticed this pattern in others besides myself and Dave. People who
> come to generic markup with a lot of experience in technology don't see
> why you need two different syntaxes for labeling information.
>
> Years later, I got used to it. From the programmer's point of view,
there's
> no difference in the degree-of-difficulty of extracting info from elements
> and attributes
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)
From whubbard at mindspring.com Tue Sep 21 20:38:00 1999
From: whubbard at mindspring.com (WHubbard)
Date: Mon Jun 7 17:15:23 2004
Subject: Unsubscribe
Message-ID: <002501bf0460$b7622fa0$1204320a@300pl>
(un)subscribe xml-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990921/12a09a9e/attachment.htm
From jsulmont at us.oracle.com Tue Sep 21 20:36:10 1999
From: jsulmont at us.oracle.com (jean-marie sulmont)
Date: Mon Jun 7 17:15:23 2004
Subject: evaluating predicate on XML documents.
Message-ID: <37E7D0B2.D849EA33@us.oracle.com>
Hi.
Could anyone please tell me what would be the best way to evaluate
predicates based on the content of XML documents?
Xpath allow to point at part of a document, and this yields to problems:
1) the sub-document pointed at may be a tree itself, or
2) assuming it's a leaf, I see no way to express a predicate (i.e.
'xpath expression' greater than 3)
If XQL (as XML query language) were out, it could be used like in:
select true from ... where PREDICATE;
Thank-you in advance,
Jean-Marie.
--
jean-marie sulmont 1000 SW Broadway suite 1200
developer Portland Oregon, 97205
Oracle Corporation Phone: (503) 525-8057
jsulmont@us.oracle.com Fax: (503) 525-8000
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)
From edd at usefulinc.com Tue Sep 21 21:30:04 1999
From: edd at usefulinc.com (Edd Dumbill)
Date: Mon Jun 7 17:15:23 2004
Subject: RFC: Attributes and XML-RPC
In-Reply-To: <001901bf0448$f45571a0$1618ccce@pebbles>; from Dave Winer on Tue, Sep 21, 1999 at 08:49:56AM -0700
References: <005901bf044c$da269350$788410d2@tigue.oz.net> <001901bf0448$f45571a0$1618ccce@pebbles>
Message-ID: <19990921193238.M20340@heddley.com>
On Tue, Sep 21, 1999 at 08:49:56AM -0700, Dave Winer wrote:
> I agree that attributes are an unfortunate and unnecessary redundancy in
> XML.
and Erik James Freed wrote:
> I would conclude that attributes were a truly unfortunate decision, and
> we will live to regret it more in the future,
Disturbing thought brewing: where would attribute-less XML leave XHTML?
(I'm not wanting to cross-pollinate the XHTML thread with this one, by
the way!)
Some interesting presumptions come up in this thread, and attitudes vary
widely dependent on whether or not one comes from an SGML background or
not.
One point worth making is that readability and easy manual authoring is
very important for XML because of its application on the Web. The best
HTML editor is still 'vi', and it can write XML too! Take the SGML and
web heritage away and XML isn't any better than J Random
Delimited-Format.
The decision facing the XML DOCTYPE creator about element vs. attributes
is just the same one as faces the creator of an SQL schema, if you take
attributes == columns and elements == tables. Perhaps because XML
documents are so easy to create we sometimes don't take as much care
over them as we would a database schema?
So if you want your spec to be free to evolve as demand requires, and
you're only likely to use machine-generated XML, there's no real need to
use attributes, agreed.
However, attributes not considered harmful.
I share in Tim's observed warm fuzzy glow from attributes, and imho
there's a pleasing, near-linguistic, aesthetic to a well-placed
attribute.
--
Edd
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)
From ricks at fourbit.com Tue Sep 21 21:00:22 1999
From: ricks at fourbit.com (Rick Sanderson)
Date: Mon Jun 7 17:15:24 2004
Subject: Xml Messaging
Message-ID: <004301bf0463$7b143ae0$0264a8c0@pompano.net>
I've been lurking this list for more than just a few messages, and
finally its time to get involved. I am surprised that I have not seen
questions like the one I'm about to ask -- I would have thought the
problem was more prevalent -- but maybe I'm in the wrong list*. (Or
maybe the issue was solved long ago and its now obvious to everyone
but me :-) Anyway...
I am working on a generic framework for client/server/distributed
apps, and have decided that XML belongs in the messaging subsystem. My
question basically boils down to this: should XML messaging be based
on a "metadata" language, or on a "domain" language?
For a simple example, consider a client application that allows the
user to display and edit the properties of a General Ledger account.
After making changes, the user saves his work, whereupon the client
messages the server.
Method 1: "Metadata" language
--------------------------------------------------------
update
Bank Account
Asset
USD
15000.00
Bank Account
Method 2: "Domain" language
-------------------------------------------------------------------
Bank Account
Asset
USD
15000.00
A response could be something similar to that from Method 1.
These two methods contrast the "Xml-Rpc" type approach, which I feel
is not appropriate for all areas of distributed client/server systems
(in the same way I feel CORBA and COM are sometimes touted
incorrectly). This opinion is based on another which says that
clients use data differently than servers, and so clients should not
be exposed to a server's fine-grained APIs, nor the object model(s)
thereof.
Rather than the details or syntax of the messages, it is more the
*general* approach (Metadata vs Domain) that I am interested in
discussing, but of course any comment at all will be graciously
welcomed.
Kind regards,
Rick Sanderson
Fourbit Group
ricks@fourbit.com
*Is there a more appropriate list/NG to which this type of inquiry
belongs? If so, I apologize in advance!
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)
From joubin at inch.com Tue Sep 21 21:31:52 1999
From: joubin at inch.com (joubin)
Date: Mon Jun 7 17:15:24 2004
Subject: Attributes vs. text content (Was Re: RFC: Attributes and XML-RPC)
Message-ID: <045c01bf0466$070078f0$a5d7f0cf@javadev.cwi.cablew.com>
I am not why HTML programmers would find attributes confusing: They must
have seen plenty of ABC 's, so an attribute
shouldn't be too much of a shock to their system.
Also,
If, as a matter of convention, one (only) uses attributes to convey element
metainfo (i.e. information _about_ the element) then, in fact, you would
have a much more coherent document (cum protocol) with clear distinction
between information and meta-information.
Consider:
xmlbased.cgi.named.foo
// .. etc.
v.s.
xmlbased.cgi.named.foo
// .. etc.
The latter mixes info and metainfo. Not a good strategy, IMO, in long haul;
specially if one is aiming for simplicity, and clarity.
Don Park wrote:
> It is true that attributes are redundant
> in a sense but they are far from
> useless.
It would be more correct to say that "attributes [could be] redundant".
They don't have to be.
So lets not get rid of attributes and start writing things like:
http://www.xyz.com
ABC
I wager most HTML 'programmers' would find _that_ confusing.
Joubin
_____________________________________________________________________
member, alpha zero LLC 202.462.1655 dc
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)
From andrewl at microsoft.com Tue Sep 21 21:43:03 1999
From: andrewl at microsoft.com (Andrew Layman)
Date: Mon Jun 7 17:15:24 2004
Subject: XHTML and the Three Namespaces
Message-ID: <5BF896CAFE8DD111812400805F1991F712E172FB@RED-MSG-08>
Here is my understanding of the XHTML namespace problem and its proposed
solution:
There is a vocabulary and syntax called "Strict". There is another called
"Transitional", and it includes elements and attributes with the same names
as those in strict, plus some additional elements and/or attributes, and the
content models and attribute lists of Transitional are such that any
document valid under "Strict" is also valid under "Transitional". There is
also a third grammar called "Frameset" having a similar, superset relation
to Transitional.
One thing that people would like is to be able to clearly define which
documents are valid per the Strict, Transitional and Frameset rules. This is
currently done via three DTDs.
Another thing people would like is to be able to indicate in a document
which set of rules the document is intended to conform to. This is done by
giving each of the three grammars a namespace, and saying that the elements
in each namespace are to be validated against the syntax in the DTD
corresponding to that namespace.
This avoids having namespace transitions within a document (as would
presumably occur if the Transitional namespace contained only those elements
additive to Strict). This approach also permits each grammar/syntax to be
described by a DTD, because we know that DTDs do not handle mixing of
namespaces gracefully. Finally, it allows that existing HTML documents
without any indication of namespaces, and consequently no namespace
transitions, may be interpreted according to the broadest grammar.
But it has the drawback that an element name from Strict and the matching
element name from Transitional have different URIs, so a namespace-capable
processor will treat them as of different element types.
The actual difference between the elements is not sustantially their
meaning, but only their content models and attribute lists.
That is, the intention of the three definitions of various elements is that
the more elaborate definition permits more elaborate content, but that an
element conforming to Strict would have the same processing consequences as
one conforming to Traditional, excepting only that a slightly different
validation test would have been performed.
Browsers, and other software specifically designed to deal with XHTML, could
deal with this fairly easily by hard-coding the relationship between the
definitions attending the three namespaces. However, generic software would
find no machine-readable connection between the namespaces, and this would
lead to awkwardness. For example, a search for documentw with "A" tags that
specified the Strict namespace would miss all documents containing
Transitional "A" tags.
Are three namespaces the right answer? Here is a provisional phrasing of
the problem we need to solve: How can we reliably distinguish elements
requiring slightly different processing, while at the same time permitting
them to be processed similarly to the degree that the differences do not
matter?
Let us look an an example to clarify the issue. Generalizing, suppose we
have an element such as
in one instance, and an element such as
in another. Although 'b' might permit additional subelements in the
content, they are not in fact there in this instance. We intend that, in
nearly all respects, a:X and b:X are processed as equivalent.
At the same time, b:X in another instance document could appear as
The content model of b:X permits subelements not permitted in a:X.
So I ask myself "Is this problem unique to XML, or has it appeared in other
contexts, and if so, how was it solved there?"
What I notice is that a very similar issue appears in languages such as Java
or C++, and is solved in the following manner:
Package A;
Class X {
Object Y;
Object Z;
}
Package B;
Class Y extends A.X {
Object W;
}
>From this I conclude that if we had a way to declare the extended content
model of B as an extension of that of A, then we would be able to express,
in a machine-readable form, the relation between b:X and a:X.
Given that, it would be proper to have three namespaces, each designating a
slightly different set of validation rules.
So our present difficulty appears to be a timing problem: the three
namespaces distinguish the different validation rules of the three
categories of elements, but there is at present no machine-readable way to
express their relationship. What we have now is readable by humans, but not
by validation programs, and what we will have eventually that is machine
readable is still under design by the Schemas working group.
Three namespaces, and the consequent mapping and other conversion processing
is certainly more expensive than if we had only one namespace, yet that
expense must be compared against other alternatives that actually solve the
problem we set out to address: How to reliably distinguish elements
requiring slightly different processing, while at the same time permitting
them to be processed similarly to the degree that the differences do not
matter?
Certainly, interpreting a document incorrectly because we did not read the
relevant definitions and mappings is not attractive. Nor is it attractive
to label different element types indistinguishably so that the relevant
definitions cannot be determined.
Of the alternatives that I have seen, only the proposal for three distinct
namespaces seems to have sufficient information in it. Perhaps I have
overlooked a proposal that also works, but at this point I conclude that the
burden of proof should rest with those who assert that the three namespace
approach is faulty, and any such proof should include a demonstration of a
workable, better alternative approach that actually solves the same problem.
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)
From greynolds at datalogics.com Tue Sep 21 21:49:01 1999
From: greynolds at datalogics.com (Reynolds, Gregg)
Date: Mon Jun 7 17:15:24 2004
Subject: RFC: Attributes and XML-RPC
Message-ID: <51ED3F5356D8D011A0B1006097C3073401B16DDD@martinique>
I can't resist chipping in my tuppence, since this touches on one of the
truly horrific aspects of the design of SGML and, yes, Groves. (Feel free
to ignore my adjectives; I'm in a hyper bolic mood.)
> -----Original Message-----
> From: Erik James Freed [mailto:ejfreed@infocanvas.com]
> Sent: Tuesday, September 21, 1999 1:03 PM
> To: xml-dev@ic.ac.uk
> Subject: RE: RFC: Attributes and XML-RPC
>
>
> My thinking is that it is considered harmful to have two ways of doing
> such semantically equivalent things, because this can easily
This is true; but it doesn't apply. Attribution is not the same as
structure; the problem is not that we have two ways of doing essentially the
same thing, its that we try to model two essentially different things in
the same way. Getting rid of attributes fixes the wrong problem. XML and
similar languages represent attempts to model the way we think, and its
pretty indisputable that the mind (well, the Western mind, in any case)
thinks about the world in terms of things, their properties, and their
relations to other things. The warm fuzzy glow Tim has observer comes, I
suspect, when people find they can think with an artificial language in the
same way they think ordinarily. Or maybe it's the relief they feel when
they realize that the computer geeks have not rammed yet another round peg
through a square hole.
A man has red hair and a dog. To suggest that his relationship with his
hair (or its redness) is no different than his relationship with his dog is,
well, shocking. It's an outrage!
>
> I would conclude that attributes were a truly unfortunate
> decision, and we
Not the fact of attribution, but the horrible way in which it is modeled,
for which we can thank SGML. "Groves" is even more monstrous in its
treatment of this.
Sincerely,
-gregg
(The opinions expressed in this screed should not be attributed to my
employer, only to me.)
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)
From john.tigue at tigue.com Tue Sep 21 22:01:16 1999
From: john.tigue at tigue.com (John Tigue)
Date: Mon Jun 7 17:15:24 2004
Subject: Attributes vs. text content
Message-ID: <009201bf0474$e09b1300$788410d2@tigue.oz.net>
joubin@inch.com wrote:
| Consider:
|
|
|
| xmlbased.cgi.named.foo
| // .. etc.
|
|
| v.s.
|
|
|
|
| xmlbased.cgi.named.foo
| // .. etc.
|
Wouldn't that be:
1.0
xmlbased.cgi.named.foo
// .. etc.
or are pseudo-attibutes ok?
/John
--
John Tigue
john.tigue@tigue.com
http://www.tigue.com
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)
From joubin at inch.com Tue Sep 21 22:29:59 1999
From: joubin at inch.com (joubin)
Date: Mon Jun 7 17:15:24 2004
Subject: Attributes vs. text content
Message-ID: <001a01bf0470$cf2e4eb0$dbd7f0cf@javadev.cwi.cablew.com>
Right you are. Nasty looking thing, isn't it?
>Wouldn't that be:
>
>
> 1.0
>
>
>
> xmlbased.cgi.named.foo
> // .. etc.
>
>
>
>or are pseudo-attibutes ok?
>
>
>/John
>
>--
>John Tigue
>john.tigue@tigue.com
>http://www.tigue.com
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)
From jesmith at kaon.com Tue Sep 21 22:34:25 1999
From: jesmith at kaon.com (Joshua E. Smith)
Date: Mon Jun 7 17:15:24 2004
Subject: Attributes vs. text content (Was Re: RFC: Attributes and
XML-RPC)
In-Reply-To: <028501bf045c$1de766f0$a24630d1@trivida.com>
References: <3.0.32.19990921090755.00b95a00@pop.intergate.bc.ca>
Message-ID: <3.0.1.32.19990921162625.008dfca0@tiac.net>
In my XML-conformant programming language (Nimble, mentioned here a couple
days ago at http://www.kaon.com/SDK ), I did what seemed to me a pretty
neat thing using attributes and elements together.
In many cases, an object (represented by an Element) needs to reference
another object. I allow the Nimble programmer to do this either as:
-or even-
I believe that a good modeling approach would be to define 'exactly' what
you
mean by the difference between hair color and pet ownership. I would guess
that you would use words like: 'sharing', 'containment', 'separability',
'ownership'
or 'lifetime'.
Lots of time has been spent in data modeling trying to understand the
simplest
constructs to capture these nuances expressively and concisely. Its hard
stuff.
Attributes versus elements is not, I would
claim, a particular elegant way to capture this, no matter how fuzzy one
subculture
feels about it. So the question is: how high level does XML want to be? One
could
consider it a low level implementation language, or a high level modeling
language
or both or something in-between, but that choice would drive both how to
handle data modeling
problems such as you are concerned with and also how to allow 'readability'
to effect
design decisions.
(I have not yet looked at Groves and perhaps this is the answer to some or
all of my wonderings...)
erik
> -----Original Message-----
> From: Reynolds, Gregg [mailto:greynolds@datalogics.com]
> Sent: Tuesday, September 21, 1999 12:52 PM
> To: 'Erik James Freed'; xml-dev@ic.ac.uk
> Subject: RE: RFC: Attributes and XML-RPC
>
>
> I can't resist chipping in my tuppence, since this touches on one of the
> truly horrific aspects of the design of SGML and, yes, Groves. (Feel free
> to ignore my adjectives; I'm in a hyper bolic mood.)
>
> > -----Original Message-----
> > From: Erik James Freed [mailto:ejfreed@infocanvas.com]
> > Sent: Tuesday, September 21, 1999 1:03 PM
> > To: xml-dev@ic.ac.uk
> > Subject: RE: RFC: Attributes and XML-RPC
> >
> >
> > My thinking is that it is considered harmful to have two ways of doing
> > such semantically equivalent things, because this can easily
>
> This is true; but it doesn't apply. Attribution is not the same as
> structure; the problem is not that we have two ways of doing
> essentially the
> same thing, its that we try to model two essentially different things in
> the same way. Getting rid of attributes fixes the wrong problem. XML and
> similar languages represent attempts to model the way we think, and its
> pretty indisputable that the mind (well, the Western mind, in any case)
> thinks about the world in terms of things, their properties, and their
> relations to other things. The warm fuzzy glow Tim has observer comes, I
> suspect, when people find they can think with an artificial
> language in the
> same way they think ordinarily. Or maybe it's the relief they feel when
> they realize that the computer geeks have not rammed yet another round peg
> through a square hole.
>
> A man has red hair and a dog. To suggest that his relationship with his
> hair (or its redness) is no different than his relationship with
> his dog is,
> well, shocking. It's an outrage!
>
> >
> > I would conclude that attributes were a truly unfortunate
> > decision, and we
>
> Not the fact of attribution, but the horrible way in which it is modeled,
> for which we can thank SGML. "Groves" is even more monstrous in its
> treatment of this.
>
> Sincerely,
>
> -gregg
> (The opinions expressed in this screed should not be attributed to my
> employer, only to me.)
>
>
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)
From Mark.Birbeck at iedigital.net Tue Sep 21 23:15:51 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun 7 17:15:24 2004
Subject: Attributes vs. text content (Was Re: RFC: Attributes and XML-
RPC)
Message-ID:
joubin wrote:
> If, as a matter of convention, one (only) uses attributes to
> convey element metainfo (i.e. information _about_ the element)
> then, in fact, you would have a much more coherent document
> (cum protocol) with clear distinction between information and
> meta-information.
>
>
> Consider:
>
>
>
> xmlbased.cgi.named.foo
> // .. etc.
>
>
> v.s.
>
>
>
>
> xmlbased.cgi.named.foo
> // .. etc.
>
>
> The latter mixes info and metainfo. Not a good strategy,
> IMO, in long haul; specially if one is aiming for simplicity,
> and clarity.
But why 'methodName' is also not 'information _about_ the element' is
not obvious. I think you'd be hard pushed to justify any particular
representation over any other - other than those that feel intuitively
right in a given situation.
Having said that, one rule I have adopted is to use attributes in
situations where I want to know something about a node without having to
read its children. This was as a consequence of developing some code to
return nodes from a server but rather than sending back all child nodes,
I simply returned XPath references to the children (a bit like the
fragments spec.). This meant that the client need only request
subsequent nodes if it wanted to. In that situation, you get better
performance by having some attribute information in the node itself,
which might help determine whether you even need to read the children.
Regards,
Mark
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)
From Mark.Birbeck at iedigital.net Tue Sep 21 23:15:50 1999
From: Mark.Birbeck at iedigital.net (Mark Birbeck)
Date: Mon Jun 7 17:15:24 2004
Subject: Xml Messaging
Message-ID:
Rick Sanderson wrote:
> I am working on a generic framework for client/server/distributed
> apps, and have decided that XML belongs in the messaging subsystem. My
> question basically boils down to this: should XML messaging be based
> on a "metadata" language, or on a "domain" language?
This raises its head in many situations, including storage (particularly
in relation to objects). I think the answer is in the realm of
validation.
Define a 'domain' language and you can validate the contents; use a
'metadata' language and you can only validate the structure of that
language. The contents could be a right mess and still get through. Of
course you could then build a validating layer on top of the 'metadata'
language, which is what RDF tends to do. If the validating you need to
do is far more elaborate than can be provided by a DOM then you lose
nothing by using a 'metadata' language, since you are going to have to
do a lot of post-parser processing anyway. Otherwise, I'd go with a
'domain' language.
Mark
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)
From john.tigue at tigue.com Tue Sep 21 23:30:23 1999
From: john.tigue at tigue.com (John Tigue)
Date: Mon Jun 7 17:15:25 2004
Subject: Announce: Prefs distribution thru XML-RPC
Message-ID: <00d101bf0481$57654490$788410d2@tigue.oz.net>
There are appropriate uses for an HTTP-tunneled, XML-syntaxed
RPC. The example that Userland gave earlier in this thread
("how to save a user's preferences") does not seem like an
appropriate use of that technology.
For a task as stateless and computation-less as persisting user
preferences an "HTTP-tunneled, XML-syntaxed RPC" is overkill
and is not yet standardized. A standards-based alternative
solution can be realized that uses only static XML 1.0
documents served by a vanilla HTTP/1.1 Web server. Corollary
benefits of the approach can also be demonstrated.
Winer said in his posting that "the focus is on simplicity".
Simplicity is a good thing so let's get out Occam's Razor:
"Pluralitas non est ponenda sine neccesitate" or "plurality
should not be posited without necessity" or "if two theories
explain the facts equally well then the simpler theory is to be
preferred" (see http://www.skepdic.com/occam.html).
In this message, I will argue that if two solutions satisfy the
same requirements then the simpler is to be preferred. The
combination of a vanilla HTTP/1.1 Web server and XML 1.0
documents is sufficient for the example and it is simpler than
the (rather proprietary) Userland XML-RPC.
Although this message seems negative towards Userland XML-RPC,
I have to give credit to Winer for sticking through all the
outrageous rigmarole that he's been put through with this
stuff. But in the end, even if XML-syntaxed RPC makes it easier
to explain PRC to folks, I don't think the benefits outweigh
the costs. Consider how many people program to DCOM and then
consider how many of them actually have ever looked at a DCOM
message on the wire. I do not believe that the global network
bandwidth and CPU costs are justified. Go HTTP-NG instead.
(Seems like memetics could justify this stuff better than any
technical argument.) If we must stay within HTTP-tunneled,
XML-syntaxed RPC then I think the protocol and the examples
need to be better before diving in.
** Terminology:
The term "vanilla HTTP/1.1 Web server" is used here to
differentiate between the well defined parts of HTTP/1.1 and
things like CGI, ASP, or any other 'dynamic' extensions to a
basic HTTP/1.1 Web server, including the Userland XML-RPC
mechanism.
Although the HTTP/1.1 spec, RFC2068, defines HTTP POST, it is
but a hook for extensibility. The behavior associated with HTTP
PUT and HTTP GET are more fully defined. By staying within the
spec, interoperability is increased. Plus the HTTP/1.1 spec
work is already done, unlike "HTTP-tunneled, XML-syntaxed
RPC".
** The situation:
Dave Winer wrote:
> Suppose you have a website that is distributed across
> several machines, perhaps geographically, with some or all
> of them serving dynamic pages with per-user customization.
> You want to provide a single place for the user to set
> preferences and have the changes percolate to the other
> servers on your internal network.
First of all, even if the application has 'dynamic' pages. The
persisting of user preference does not need to be dynamic (see
below).
If it is a multi-machine website, I assume that there is a
single HTTP server (a reverse proxy) which has the public
Internet IP address for the site. That server farms out the
HTTP requests to the appropriate worker Web server, that is,
the other machines which are part of the site. For a discussion
of reverse proxies see:
http://www.webtechniques.com/archives/1998/05/engelschall/
Of course if we are just talking RPCing between servers then
CORBA or DCOM would work. RPC can already go over the Web via
HTTP tunnelling. For example consider Microsoft:
http://msdn.microsoft.com/library/sdkdoc/rpc/ov-http_1zw0.htm
So, consider using an existing piece of technology which solves
the problem better than any current XML-syntaxed RPC mechanism.
Plus there are more existing developer tools available for
CORBA and DCOM. Perhaps use XML-syntaxed RPC for research but
not for deploying applications now.
** The Userland XML-RPC solution:
Let me see if I understand what's being described.
Dave Winer wrote:
> We had to build such a preferences distribution network for
> UserLand.Com, and naturally we used XML-RPC to implement it.
>
> The interface is easy to implement once you have an XML-RPC
> layer running.
That's a big assumption. What percentage of the currently
deployed web servers have this "XML-RPC layer"? If an
admin is newly adding this layer to a server then which spec
should be choosen: the Userland XML-RPC spec or the
one that Userland submitted with Microsoft, called SOAP?
There's a very big difference between the two: they don't
interoperate, that is, a SOAP talking machine can't discourse
with a Userland XML-RPC talking machine (unless there's a newer
Userland XML-RPC spec I haven't seen although the last one I
looked at was referenced by Winer on Mon, 20 Sep 1999 in:
www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0973.html
so I don't think that I've missed a new one). Of course, a
machine could talk both protocols but that does not seem
simple.
I find Userland's market positioning of Userland XML-RPC
vs. SOAP very confusing. Especially with statements from
Userland such as the following:
davenet.userland.com/1999/09/12/anEndToTheUberoperatingSystem
> Two levels of XML-RPC
> So there are now two levels of XML-RPC. Here's a pointer to the
> specification for the simple protocol:
> http://www.xmlrpc.com/spec
> And here's a pointer to the new specification:
> http://www.xmlrpc.com/soap
> It's your choice. Either spec will work. We support both. Let's
> have fun!
>From "Two levels" I infer interoperability as if Userland
XML-RPC were a proper subset of SOAP. Perhaps I'm simply
confused by their terminology; maybe "XML-RPC" and "Userland
XML-RPC" are different things in their vocabulary. If so, then
someone needs to talk to the marketing department. At the very
least they seem to be saying they have an offering which works
with both XML-RPC and SOAP. I'm confused. Of course, he goes on
to say:
> Finally, every big company will probably launch their own
> specification. Implementors should be aware of this, and should
> plan their software interfaces accordingly. Expect wiring-level
> incompatibility and you won't be surprised.
Not surprised but still not working.
Back to Winer's message:
> It consists of a single RPC handler,
> updateMemberInfo, on each of the affiliate machines.
So each machine needs to deploy an "HTTP-tunneled, XML-syntaxed
RPC" mechanism. A less onerous lowest common denominator would
be nice (see below).
> It's a little more complicated on the preferences hub -- it
has to
> implement a database of affiliated machines, and call each
> machine when a preference is updated.
So this solution needs a database (and some DBMS?) and a
notification mechanism(?).
> On either side, it's a very easy implementation and it
> delivers a feature that users want.
OK, but I don't think there are any users saying "I want my
preferences managed via Userland XML-RPC." So, there's a
requirement but no constraint on the implementation.
> Like all the next-level-up specs we're doing for XML-RPC the
> focus is on simplicity, and should work equally well with
> SOAP or other transport-level protocols.
Winer references the following URL:
http://www.xmlrpc.com/stories/storyReader$496
There we find an example methodCall for persisting preferences:
updateMemberInfo
default
bull@mancuso.com
appearance.alink
pink
appearance.bgcolor
beige
appearance.link
navy
appearance.text
black
appearance.vlink
teal
The above says that bull@mancuso.com wishes to persist his
preferences for the following:
appearance.alink
appearance.bgcolor
appearance.link
appearance.text
appearance.vlink
And for some reason that I do not understand the (supposedly)
universally unique email string "bull@mancuso.com" is
insufficient to resolve to the correct user's persistent store
so Userland needs a group name (in this case "default") to
help. Perhaps this is an artifact of the black box where in all
this info really ends up getting stored. Or maybe there's some
legacy directory service stuff going on.
Speaking of black boxes, what happens if Userland folds? One of
the reasons that SQL became so popular was that it is easy to
migrate from vendor to vendor. If it comes time to migrate, it
would appear to be simpler to apply some transforms to an HTTP
collection of XML documents than extract the data from
Userland's system (or any other early "HTTP-tunneled,
XML-syntaxed RPC" system). For example, how do you enumerate
over the preferences of all the users in Userland's system?
With HTTP/1.1 you would just do a GET on the collection and
then a GET on each document in the collection (and then
transform each document).
Finally, in this "persist user preferences" example I don't see
any "state" being maintained in software objects (e.g. of
state: "please add the following numbers together, then add
them to the historic running total resulting from my previous
RPC calls and return to me the sum and don't forget to remember
my running total for the next time I call you."). If an
application needs to maintain state between method calls then
there is an argument for RPC. I could even see a reason for a
stateless object which does some computation (e.g. "please add
the following numbers together and give me the sum" i.e. no
state maintenance such as a "historic running total") but a
pure persistence problem does not require even this.
** An HTTP/1.1 and XML 1.0 solution:
An alternative solution would seem possible using simply
a vanilla HTTP/1.1 Web server and XML 1.0 documents.
We could just cook up something like:
pink
beige
navy
black
teal
Then we could simply HTTP PUT the doc to a Web server at an
URL, say, example.com/userprefs/bull%40mancuso.com ('@' is
reserved in URIs so "%40" instead). This solution requires
nothing more than vanilla Apache (or any generic HTTP/1.1
server).
Further, with this solution an end-user could control where the
preferences are to be stored. They could be parked on any
HTTP/1.1 server where the end-user has PUT permissions. Perhaps
the end-user likes privacy. In that case the preferences could
be stored in a HTTPd in the localhost, that is, the info would
never leave the client machine.
Consider what happens if this user preferences persisting
mechanism is to be shared with other sites? The two sites could
simply agree on areas of their Web servers where some XML docs
can be PUT to the servers. To do that in the Userland XML-RPC
way requires...(see above).
With this solution I could also benefit from HTTP caching and
If-Modified-Since for a simpler, cheaper, and more scalable
solution.
** Conclusion
It seems that in Userland's offering XML-RPC is being used as a
complicated replacement for HTTP PUT and HTTP GET. I know this
is no surprise to the folks on this list, but there will always
be some 'static' document publishing nature to the Web. So
things like HTTP GET and HTTP PUT aren't going away any time
soon. So use Occam's razor and use what you've already got:
HTTP/1.1 and XML 1.0. No need to posit a plurality.
I'm just guessing at Userland's situation but if it's anything
like the above picture, I would think hard before deploying the
solution. Perhaps I am missing something.
Time to get off the SOAP-box,
/John
--
John Tigue
john.tigue@tigue.com
http://www.tigue.com
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)
From ssahuc at imediation.com Tue Sep 21 23:31:11 1999
From: ssahuc at imediation.com (Sebastien Sahuc)
Date: Mon Jun 7 17:15:25 2004
Subject: Elements cannot be described more than once in DTD, right ?
Message-ID:
Hello,
I have an element () than can have different set of sub
element. How can I describe it in DTD ?
For example :
and :
How can I express in DTD that affiliate operations in 'set' and 'get',
and that merchant has only the 'signup' ?
Thank for any reply you should provide.
Sebastien Sahuc
ssahuc@imediation.com
> -----Original Message-----
> From: Joshua E. Smith [mailto:jesmith@kaon.com]
> Sent: mardi 21 septembre 1999 22:26
> To: XML Developers' List
> Subject: Re: Attributes vs. text content (Was Re: RFC: Attributes
and
> XML-RPC)
>
>
> In my XML-conformant programming language (Nimble, mentioned
> here a couple
> days ago at http://www.kaon.com/SDK ), I did what seemed to
> me a pretty
> neat thing using attributes and elements together.
>
> In many cases, an object (represented by an Element) needs to
> reference
> another object. I allow the Nimble programmer to do this either as:
>
>
>
>
> -or even-
>
>
>
>
Point well taken, and this just shows to go you that mixing implementation
and abstraction causes funny things to happen. And lets be fair about what
an 'attributeless' XML might look like:
1.0
http://www.w3.org/rpc
http://www.w3.org/html
http://www.w3.org/xql
http://www.w3.org/xtype
asynchronous
callback
xmlbased.cgi.named.foo
1
foo.bar.goo
binary-reverse
foo/*&//.$^#
2
foo.bar.text
ISO9087345
binary-reverse
this is a paragraph
Is this potential full featured RPC more or less readable than its
equivalent using attributes?
Useability studies in my experience (YMMV) show that what one is used to
often seems the 'easiest' or 'best' and this works in both directions, even
if
there are absolute comprehension or speed issues with one or the other. I
can
mention that the above seems more readable to *me*, but I come from a
different background,
and it is merely subjective anecdotal evidence.
Again, I am not trying to redefine XML fundamentals on the fly in a few
emails, but I think that
the issues are more complicated and far reaching than is being admitted
here.
Thoug again, and even more importantly, this is all quite moot as it is not
going to change.
erik
> -----Original Message-----
> From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> John Tigue
> Sent: Tuesday, September 21, 1999 2:04 PM
> To: xml-dev
> Subject: Re: Attributes vs. text content
>
>
> joubin@inch.com wrote:
> | Consider:
> |
> |
> |
> | xmlbased.cgi.named.foo
> | // .. etc.
> |
> |
> | v.s.
> |
> |
> |
> |
> | xmlbased.cgi.named.foo
> | // .. etc.
> |
>
>
> Wouldn't that be:
>
>
> 1.0
>
>
>
> xmlbased.cgi.named.foo
> // .. etc.
>
>
>
> or are pseudo-attibutes ok?
>
>
> /John
>
> --
> John Tigue
> john.tigue@tigue.com
> http://www.tigue.com
>
>
>
> 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)
>
>
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)
From dave at userland.com Wed Sep 22 00:15:47 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun 7 17:15:25 2004
Subject: Announce: Prefs distribution thru XML-RPC
References: <00d101bf0481$57654490$788410d2@tigue.oz.net>
Message-ID: <00d301bf047f$a8433e00$1618ccce@pebbles>
John, I can save you some trouble -- you don't have to tie into this
network. Our customers want it. We also promised that we wouldn't lock them
in to UserLand-only solutions. So as long as we're providing an open
interface, which we are, we have to announce what we're doing, why not tell
the XML-DEV list about it. I don't expect the world to galvanize around our
solution unless it's the right thing to do.
As to why we continue with XML-RPC even though SOAP is out, it's pragmatic.
We have a lot of stuff we do with XML-RPC. Our SOAP interfaces aren't even
slightly deployed yet. That's a kind way of saying that at this time our
*only8 choice is XML-RPC. You're right, the vast majority of messages are
unexamined. It could be that this time next year all our messages will be
SOAP-encoded. That would be fine with me. I'm interested in the next-level
up, and am keeping the options open in case more developers prefer the
simpler format. The jury is still out on that.
About whether or not static XML files would do, of course you could do a
polling thing, but this is a lot simpler to implement, again, assuming you
have an XML-RPC layer. If you don't no problem, do the static file thing.
Have fun. Be a pioneer.
This is a lot less heavy than you think. Let's have fun. If this doesn't
become a standard there will still be a Christmas and the birds will still
sing.
***More philosophy
Since you're quoting from DaveNet, let me do the same. From "Sell What You
Have" :
http://davenet.userland.com/1997/01/05/SellWhatYouHave
I remember a conversation with Jean-Louis Gassee in 1989, when he was head
of Apple's product development. We were talking about the scripting software
I was developing, which eventually became Frontier.
We also talked about HyperCard, which was then the most powerful scripting
software for the Macintosh. I said (of course) that our software would be
much more sophisticated than HyperCard, more for geeks, but simpler, deeper,
faster, more useful. Jean-Louis encouraged me to tell him more. I did. I
like talking to JLG because he likes geek talk.
So then he asked me a question that I still think about. He asked, "Would it
be all right with you, if in the meantime, we continued to sell HyperCard?"
I laughed! I'm laughing now. It's a funny question!
"Yes, of course," I said; secretly wishing that he would immediately lose
interest in HyperCard, and commit fully to my new system scripting design.
I'm just a human being, looking for the easier path, for me, of course.
His question is still teaching me lessons, and looking at the history of
Apple, which is anything but Sell What You Have, it seems, based on reading
tea leaves, that we are probably going to get a chance to learn more about
this next week.
***Anyway
That's my philosophy. I'm selling what I have. You don't want to buy. OK.
But you never know how it's going to turn out. I've seen platform vendors
trip up, even Microsoft. Sometimes the low-tech solution wins. Actually if
you look at the way the Internet works, you might conclude that the low-tech
solution *always* wins.
One more thing, it's totally not fair to call this UserLand XML-RPC. Look at
the home page of the site, there are independent implementations done for
lots of different languages and environments, and none of these were done by
UserLand. And the initial design was done by Developmentor, Microsoft and
UserLand. You're too smart John to do that accidentally, so please be more
careful.
Dave
----- Original Message -----
From: John Tigue
To: xml-dev
Sent: Tuesday, September 21, 1999 3:33 PM
Subject: Re: Announce: Prefs distribution thru XML-RPC
>
> There are appropriate uses for an HTTP-tunneled, XML-syntaxed
> RPC. The example that Userland gave earlier in this thread
> ("how to save a user's preferences") does not seem like an
> appropriate use of that technology.
>
> For a task as stateless and computation-less as persisting user
> preferences an "HTTP-tunneled, XML-syntaxed RPC" is overkill
> and is not yet standardized. A standards-based alternative
> solution can be realized that uses only static XML 1.0
> documents served by a vanilla HTTP/1.1 Web server. Corollary
> benefits of the approach can also be demonstrated.
>
> Winer said in his posting that "the focus is on simplicity".
> Simplicity is a good thing so let's get out Occam's Razor:
> "Pluralitas non est ponenda sine neccesitate" or "plurality
> should not be posited without necessity" or "if two theories
> explain the facts equally well then the simpler theory is to be
> preferred" (see http://www.skepdic.com/occam.html).
>
> In this message, I will argue that if two solutions satisfy the
> same requirements then the simpler is to be preferred. The
> combination of a vanilla HTTP/1.1 Web server and XML 1.0
> documents is sufficient for the example and it is simpler than
> the (rather proprietary) Userland XML-RPC.
>
> Although this message seems negative towards Userland XML-RPC,
> I have to give credit to Winer for sticking through all the
> outrageous rigmarole that he's been put through with this
> stuff. But in the end, even if XML-syntaxed RPC makes it easier
> to explain PRC to folks, I don't think the benefits outweigh
> the costs. Consider how many people program to DCOM and then
> consider how many of them actually have ever looked at a DCOM
> message on the wire. I do not believe that the global network
> bandwidth and CPU costs are justified. Go HTTP-NG instead.
> (Seems like memetics could justify this stuff better than any
> technical argument.) If we must stay within HTTP-tunneled,
> XML-syntaxed RPC then I think the protocol and the examples
> need to be better before diving in.
>
>
> ** Terminology:
> The term "vanilla HTTP/1.1 Web server" is used here to
> differentiate between the well defined parts of HTTP/1.1 and
> things like CGI, ASP, or any other 'dynamic' extensions to a
> basic HTTP/1.1 Web server, including the Userland XML-RPC
> mechanism.
>
> Although the HTTP/1.1 spec, RFC2068, defines HTTP POST, it is
> but a hook for extensibility. The behavior associated with HTTP
> PUT and HTTP GET are more fully defined. By staying within the
> spec, interoperability is increased. Plus the HTTP/1.1 spec
> work is already done, unlike "HTTP-tunneled, XML-syntaxed
> RPC".
>
>
> ** The situation:
> Dave Winer wrote:
> > Suppose you have a website that is distributed across
> > several machines, perhaps geographically, with some or all
> > of them serving dynamic pages with per-user customization.
> > You want to provide a single place for the user to set
> > preferences and have the changes percolate to the other
> > servers on your internal network.
>
> First of all, even if the application has 'dynamic' pages. The
> persisting of user preference does not need to be dynamic (see
> below).
>
> If it is a multi-machine website, I assume that there is a
> single HTTP server (a reverse proxy) which has the public
> Internet IP address for the site. That server farms out the
> HTTP requests to the appropriate worker Web server, that is,
> the other machines which are part of the site. For a discussion
> of reverse proxies see:
> http://www.webtechniques.com/archives/1998/05/engelschall/
>
> Of course if we are just talking RPCing between servers then
> CORBA or DCOM would work. RPC can already go over the Web via
> HTTP tunnelling. For example consider Microsoft:
> http://msdn.microsoft.com/library/sdkdoc/rpc/ov-http_1zw0.htm
>
> So, consider using an existing piece of technology which solves
> the problem better than any current XML-syntaxed RPC mechanism.
> Plus there are more existing developer tools available for
> CORBA and DCOM. Perhaps use XML-syntaxed RPC for research but
> not for deploying applications now.
>
>
> ** The Userland XML-RPC solution:
> Let me see if I understand what's being described.
>
> Dave Winer wrote:
> > We had to build such a preferences distribution network for
> > UserLand.Com, and naturally we used XML-RPC to implement it.
> >
> > The interface is easy to implement once you have an XML-RPC
> > layer running.
>
> That's a big assumption. What percentage of the currently
> deployed web servers have this "XML-RPC layer"? If an
> admin is newly adding this layer to a server then which spec
> should be choosen: the Userland XML-RPC spec or the
> one that Userland submitted with Microsoft, called SOAP?
> There's a very big difference between the two: they don't
> interoperate, that is, a SOAP talking machine can't discourse
> with a Userland XML-RPC talking machine (unless there's a newer
> Userland XML-RPC spec I haven't seen although the last one I
> looked at was referenced by Winer on Mon, 20 Sep 1999 in:
> www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0973.html
> so I don't think that I've missed a new one). Of course, a
> machine could talk both protocols but that does not seem
> simple.
>
> I find Userland's market positioning of Userland XML-RPC
> vs. SOAP very confusing. Especially with statements from
> Userland such as the following:
> davenet.userland.com/1999/09/12/anEndToTheUberoperatingSystem
>
> > Two levels of XML-RPC
> > So there are now two levels of XML-RPC. Here's a pointer to the
> > specification for the simple protocol:
> > http://www.xmlrpc.com/spec
> > And here's a pointer to the new specification:
> > http://www.xmlrpc.com/soap
> > It's your choice. Either spec will work. We support both. Let's
> > have fun!
>
> From "Two levels" I infer interoperability as if Userland
> XML-RPC were a proper subset of SOAP. Perhaps I'm simply
> confused by their terminology; maybe "XML-RPC" and "Userland
> XML-RPC" are different things in their vocabulary. If so, then
> someone needs to talk to the marketing department. At the very
> least they seem to be saying they have an offering which works
> with both XML-RPC and SOAP. I'm confused. Of course, he goes on
> to say:
>
> > Finally, every big company will probably launch their own
> > specification. Implementors should be aware of this, and should
> > plan their software interfaces accordingly. Expect wiring-level
> > incompatibility and you won't be surprised.
>
> Not surprised but still not working.
>
>
> Back to Winer's message:
> > It consists of a single RPC handler,
> > updateMemberInfo, on each of the affiliate machines.
>
> So each machine needs to deploy an "HTTP-tunneled, XML-syntaxed
> RPC" mechanism. A less onerous lowest common denominator would
> be nice (see below).
>
> > It's a little more complicated on the preferences hub -- it
> has to
> > implement a database of affiliated machines, and call each
> > machine when a preference is updated.
>
> So this solution needs a database (and some DBMS?) and a
> notification mechanism(?).
>
> > On either side, it's a very easy implementation and it
> > delivers a feature that users want.
>
> OK, but I don't think there are any users saying "I want my
> preferences managed via Userland XML-RPC." So, there's a
> requirement but no constraint on the implementation.
>
> > Like all the next-level-up specs we're doing for XML-RPC the
> > focus is on simplicity, and should work equally well with
> > SOAP or other transport-level protocols.
>
> Winer references the following URL:
> http://www.xmlrpc.com/stories/storyReader$496
> There we find an example methodCall for persisting preferences:
>
>
> updateMemberInfo
>
> default
>
> bull@mancuso.com
>
>
>
>
> appearance.alink
> pink
>
>
> appearance.bgcolor
> beige
>
>
> appearance.link
> navy
>
>
> appearance.text
> black
>
>
> appearance.vlink
> teal
>
>
>
>
>
>
>
> The above says that bull@mancuso.com wishes to persist his
> preferences for the following:
> appearance.alink
> appearance.bgcolor
> appearance.link
> appearance.text
> appearance.vlink
>
> And for some reason that I do not understand the (supposedly)
> universally unique email string "bull@mancuso.com" is
> insufficient to resolve to the correct user's persistent store
> so Userland needs a group name (in this case "default") to
> help. Perhaps this is an artifact of the black box where in all
> this info really ends up getting stored. Or maybe there's some
> legacy directory service stuff going on.
>
> Speaking of black boxes, what happens if Userland folds? One of
> the reasons that SQL became so popular was that it is easy to
> migrate from vendor to vendor. If it comes time to migrate, it
> would appear to be simpler to apply some transforms to an HTTP
> collection of XML documents than extract the data from
> Userland's system (or any other early "HTTP-tunneled,
> XML-syntaxed RPC" system). For example, how do you enumerate
> over the preferences of all the users in Userland's system?
> With HTTP/1.1 you would just do a GET on the collection and
> then a GET on each document in the collection (and then
> transform each document).
>
> Finally, in this "persist user preferences" example I don't see
> any "state" being maintained in software objects (e.g. of
> state: "please add the following numbers together, then add
> them to the historic running total resulting from my previous
> RPC calls and return to me the sum and don't forget to remember
> my running total for the next time I call you."). If an
> application needs to maintain state between method calls then
> there is an argument for RPC. I could even see a reason for a
> stateless object which does some computation (e.g. "please add
> the following numbers together and give me the sum" i.e. no
> state maintenance such as a "historic running total") but a
> pure persistence problem does not require even this.
>
>
> ** An HTTP/1.1 and XML 1.0 solution:
> An alternative solution would seem possible using simply
> a vanilla HTTP/1.1 Web server and XML 1.0 documents.
>
> We could just cook up something like:
>
> pink
> beige
> navy
> black
> teal
>
>
> Then we could simply HTTP PUT the doc to a Web server at an
> URL, say, example.com/userprefs/bull%40mancuso.com ('@' is
> reserved in URIs so "%40" instead). This solution requires
> nothing more than vanilla Apache (or any generic HTTP/1.1
> server).
>
> Further, with this solution an end-user could control where the
> preferences are to be stored. They could be parked on any
> HTTP/1.1 server where the end-user has PUT permissions. Perhaps
> the end-user likes privacy. In that case the preferences could
> be stored in a HTTPd in the localhost, that is, the info would
> never leave the client machine.
>
> Consider what happens if this user preferences persisting
> mechanism is to be shared with other sites? The two sites could
> simply agree on areas of their Web servers where some XML docs
> can be PUT to the servers. To do that in the Userland XML-RPC
> way requires...(see above).
>
> With this solution I could also benefit from HTTP caching and
> If-Modified-Since for a simpler, cheaper, and more scalable
> solution.
>
>
>
> ** Conclusion
> It seems that in Userland's offering XML-RPC is being used as a
> complicated replacement for HTTP PUT and HTTP GET. I know this
> is no surprise to the folks on this list, but there will always
> be some 'static' document publishing nature to the Web. So
> things like HTTP GET and HTTP PUT aren't going away any time
> soon. So use Occam's razor and use what you've already got:
> HTTP/1.1 and XML 1.0. No need to posit a plurality.
>
> I'm just guessing at Userland's situation but if it's anything
> like the above picture, I would think hard before deploying the
> solution. Perhaps I am missing something.
>
> Time to get off the SOAP-box,
> /John
>
>
> --
> John Tigue
> john.tigue@tigue.com
> http://www.tigue.com
>
>
>
>
>
>
>
> 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)
>
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)
From joubin at inch.com Wed Sep 22 00:34:02 1999
From: joubin at inch.com (joubin)
Date: Mon Jun 7 17:15:25 2004
Subject: Attributes vs. text content (Was Re: RFC: Attributes and XML-RPC)
Message-ID: <001201bf0482$23aaa9f0$8fd7f0cf@javadev.cwi.cablew.com>
-----Original Message-----
From: Mark Birbeck
>But why 'methodName' is also not 'information _about_ the element' is
>not obvious.
That _is_ a good point. However, this is someone else's protocol.
// .. etc.
This would work too, I suppose.
Best Regards,
Joubin
_____________________________________________________________________
member, alpha zero LLC 202.462.1655 dc
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)
From ceo at citix.com Wed Sep 22 00:37:24 1999
From: ceo at citix.com (Steven Livingstone)
Date: Mon Jun 7 17:15:25 2004
Subject: RFC: Attributes and XML-RPC
Message-ID: <00b901bf0482$b60677c0$0a0a0a0a@deltabiz>
> Would it not also be true that using attributes rather than elements can
> also be more efficient in certain situations?
>
> In XML messaging for example, would it not be more efficient to use
> attributes accross the wire.
>
> Consider
>
>
> Steven
>
> 24
>
> 1.87
>
> 7
>
>
>
> and an equivalent with attributes
>
>
>
> The first has 79 characters and the second has 52. If we transferred 10
> peoples information accross the wires, we would need 270 "redundant"
> characters (2700 with 100 persons) !! 10 persons *is not* a lot of data
for
> the applications I often write.
>
> In the world of transferring data across the wire, this may be pretty
> important, especially with the recent converstions on XML-bin (binary XML)
> and the desire to speed up XML.
>
> Does everyone disagree?
>
> Cheers
> Steven
>
> Steven Livingstone
> Glasgow, Scotland.
> +44 7771 957 280
>
> Author -
> Professional Site Server 3, Wrox Press
> http://www.wrox.com/Store/Details.asp?Code=2696
> Professional Site Server 3.0 Commerce Edition, Wrox Press
> http://www.wrox.com/Store/Details.asp?Code=2505
>
> President, AIP Scotland.
> ceo@citix.com
> http://www.citix.com
>
> Join Association of Internet Professionals - http://www.citix.com/aip
> ----- Original Message -----
> From: Don Park
> To:
> Sent: Tuesday, September 21, 1999 6:11 PM
> Subject: RE: RFC: Attributes and XML-RPC
>
>
> > It is true that attributes are redundant in a sense but they are far
from
> > useless.
> >
> > Its unobtrusive nature helps solve problems like XML Namespace. As Tim
> > mentioned, it does enhance readability. DTD is a lot more friendly to
> > attributes. With attributes, you can enforce 'just-once' constraint
> without
> > schema. XHTML would look awefully funny without attributes. The list
> goes
> > on and on.
> >
> > Redundancy seems like a waste until one ends up between a rock and a
hard
> > place.
> >
> > Best,
> >
> > Don Park - mailto:donpark@docuverse.com
> > Docuverse - http://www.docuverse.com
> >
> >
> > 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)
> >
> >
>
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)
From mrc at allette.com.au Wed Sep 22 00:41:11 1999
From: mrc at allette.com.au (Marcus Carr)
Date: Mon Jun 7 17:15:25 2004
Subject: Elements cannot be described more than once in DTD, right ?
References:
Message-ID: <37E80A0E.6D90E406@allette.com.au>
Sebastien Sahuc wrote:
> I have an element () than can have different set of sub
> element. How can I describe it in DTD ?
>
> For example :
>
>
>
>
>
> and :
>
>
>
>
>
>
> How can I express in DTD that affiliate operations in 'set' and 'get',
> and that merchant has only the 'signup' ?
This may be over-simplifying the problem, but I would just lose the operation element and
define affiliate and merchant as:
The operations element seems redundant, unless the contents of affiliate and merchant can be
more complex than you have indicated.
--
Regards,
Marcus Carr email: mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia) www: http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
- Einstein
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)
From ejfreed at infocanvas.com Wed Sep 22 01:13:09 1999
From: ejfreed at infocanvas.com (Erik James Freed)
Date: Mon Jun 7 17:15:26 2004
Subject: RFC: Attributes and XML-RPC
In-Reply-To: <00b901bf0482$b60677c0$0a0a0a0a@deltabiz>
Message-ID:
That is an excellent implementation versus modeling language distinction. It
is more efficient to use
attributes but much more efficient still to go to binary formats which
hopefully we can all agree are intensely unreadable :-)
> -----Original Message-----
> From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
> Steven Livingstone
> Sent: Tuesday, September 21, 1999 3:43 PM
> To: 'XML Dev'
> Subject: Re: RFC: Attributes and XML-RPC
>
>
> > Would it not also be true that using attributes rather than elements can
> > also be more efficient in certain situations?
> >
> > In XML messaging for example, would it not be more efficient to use
> > attributes accross the wire.
> >
> > Consider
> >
> >
> > Steven
> >
> > 24
> >
> > 1.87
> >
> > 7
> >
> >
> >
> > and an equivalent with attributes
> >
> >
> >
> > The first has 79 characters and the second has 52. If we transferred 10
> > peoples information accross the wires, we would need 270 "redundant"
> > characters (2700 with 100 persons) !! 10 persons *is not* a lot of data
> for
> > the applications I often write.
> >
> > In the world of transferring data across the wire, this may be pretty
> > important, especially with the recent converstions on XML-bin
> (binary XML)
> > and the desire to speed up XML.
> >
> > Does everyone disagree?
> >
> > Cheers
> > Steven
> >
> > Steven Livingstone
> > Glasgow, Scotland.
> > +44 7771 957 280
> >
> > Author -
> > Professional Site Server 3, Wrox Press
> > http://www.wrox.com/Store/Details.asp?Code=2696
> > Professional Site Server 3.0 Commerce Edition, Wrox Press
> > http://www.wrox.com/Store/Details.asp?Code=2505
> >
> > President, AIP Scotland.
> > ceo@citix.com
> > http://www.citix.com
> >
> > Join Association of Internet Professionals - http://www.citix.com/aip
> > ----- Original Message -----
> > From: Don Park
> > To:
> > Sent: Tuesday, September 21, 1999 6:11 PM
> > Subject: RE: RFC: Attributes and XML-RPC
> >
> >
> > > It is true that attributes are redundant in a sense but they are far
> from
> > > useless.
> > >
> > > Its unobtrusive nature helps solve problems like XML
> Namespace. As Tim
> > > mentioned, it does enhance readability. DTD is a lot more friendly to
> > > attributes. With attributes, you can enforce 'just-once' constraint
> > without
> > > schema. XHTML would look awefully funny without attributes. The list
> > goes
> > > on and on.
> > >
> > > Redundancy seems like a waste until one ends up between a rock and a
> hard
> > > place.
> > >
> > > Best,
> > >
> > > Don Park - mailto:donpark@docuverse.com
> > > Docuverse - http://www.docuverse.com
> > >
> > >
> > > 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)
> >
> >
>
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)
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)
From Marc.McDonald at Design-Intelligence.com Wed Sep 22 01:37:51 1999
From: Marc.McDonald at Design-Intelligence.com (Marc.McDonald@Design-Intelligence.com)
Date: Mon Jun 7 17:15:26 2004
Subject: XHTML and the Three Namespaces
Message-ID: <4454C011BDE5D211B6C800609776E540268339@master.design-intelligence.com>
> :
>
Andrew Layman wrote:
> One thing that people would like is to be able to clearly define which
> documents are valid per the Strict, Transitional and Frameset rules. This
> is
> currently done via three DTDs.
>
Fine, though I would argue for a single DTD with conditionals.
> Another thing people would like is to be able to indicate in a document
> which set of rules the document is intended to conform to. This is done by
> giving each of the three grammars a namespace, and saying that the
> elements
> in each namespace are to be validated against the syntax in the DTD
> corresponding to that namespace.
>
I assume you mean including XHTML in some non-XHTML document. First, this is
a general XML problem not an XHTML problem and should be addressed by
schemas not second-guessed. Second, there is no way to associate a namespace
with a DTD and force validation in XML 1.0. Third, the DTD for the outer
document would have to include definitions for the XHTML elements in which
case the appropriate definition could be chosen. What use is it to validate
a section of XHTML when the entire document would fail validation? You are
describing significant changes to validation mechanisms which are in no way
part of XHTML's responsiblity.
story.dtd
...
...
story.xml:
...
here's some XHTML text
instead of ?
I could say that you solution doesn't solve the problem without significant
changes to the nature of validation and XML processing. You have focused in
on validating a fragment of XHTML in a docuemtn and forgotten about
validating the rest of the document. Why is the fragment so special?
Simple solution:
1. If the document is XHTML, use the appropriate DTD in the DOCTYPE
declaration
2. If you want a document that can be validated and includes XHTML, modify
your DTD to include the XHTML element and attribute definitions of choice
from the modularization files. If there is a conflict between XHTML elements
and the rest of the document grammer, use a namespace prefix.
3. If the document is not validated, only well-formedness is guaranteed.
4a. An application can recognize XHTML elements because they aren't any of
the elements that were defined in its grammer (i.e. application has code
that know what element's it processes and which aren't anyway).
or
4b. Add a default attribute to the XHTML modules, htmltype, which defaults
to 'strict', 'transitional', or 'frameset' and have the application check
for it (a convention just like using parameter entities for re-use). You
could even allow "strict, transitional" as a value if it is the same in
both.
This needs to work under XML 1.0, not XML modified for schemas. Use what 1.0
provides. The modules are being constructed under the asumption of XML 1.0 -
using multiple files and parameter entities, do the same for this.
Marc B. McDonald
Principal Software Scientist
Design Intelligence, Inc.
1111 Third Avenue, Suite 1500
Seattle, WA 98101
marc.mcdonald@design-intelligence.com
Ph: 206.343-7797
Fax: 206.343.7750
http://www.design-intelligence.com
> 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)
>
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)
From mrc at allette.com.au Wed Sep 22 02:08:14 1999
From: mrc at allette.com.au (Marcus Carr)
Date: Mon Jun 7 17:15:26 2004
Subject: RFC: Attributes and XML-RPC
References: <005901bf044c$da269350$788410d2@tigue.oz.net> <199909211621.MAA32402@hesketh.net> <003e01bf0451$86297830$1618ccce@pebbles>
Message-ID: <37E81E75.C8B49852@allette.com.au>
Dave Winer wrote:
> Attributes are for wispy little very optional things, if they are for
> anything at all.
Wispy little things like security levels? How would you represent the following pseudo-defence
data:
Wheeled Armoured Toys
WATs are your friend...
The two options that come to mind are either:
u
Wheeled Armoured Toys
u
WATs are your friend...
u
... which requires the evaluation of a child element before the application is able to
understand how to deal with an elements such as para0 or para, (presumably the values are
inherited) or something like:
Wheeled Armoured Toys
WATs are your friend...
... which obviously requires a ridiculously loose content model for element u and any other
value that may have been assigned to the security level.
I find attributes to be cleaner to look at and more logical to apply than elements, though I
admit that the nature of the data may blur this distinction. Perhaps consideration of the
diverse nature of data might have lead you to word your (copied) opening statement less
emphatically?
--
Regards,
Marcus Carr email: mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia) www: http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
- Einstein
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)
From zepho at flashemail.com Wed Sep 22 02:26:18 1999
From: zepho at flashemail.com (Flash Gordon)
Date: Mon Jun 7 17:15:26 2004
Subject: IBMs XML for Java and JBuilder
Message-ID: <-121379261.937960591508.JavaMail.Administrator@harley>
Greetings XML Gurus,
I am using IBMs XML4J 2.0.15. I would like to use it with JBuilder 3.0. I created a new library and provided the source path (zip file) and the classpath (jar file) in the Project-> properties window. The JBuilder is not able to compile the examples which contains the com.ibm.*. How do I make the JBuilder aware of the com.ibm.* packages ? I am on Windows 98, the classpath variable does point to the xml4j.jar file.
Thanks for your time,
Bala
Flash Gordon
____________________________________________________
get your permanent, free email at http://www.flashemail.com
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)
From srn at techno.com Wed Sep 22 02:26:53 1999
From: srn at techno.com (Steven R. Newcomb)
Date: Mon Jun 7 17:15:26 2004
Subject: RFC: Attributes and XML-RPC
In-Reply-To: <51ED3F5356D8D011A0B1006097C3073401B16DDD@martinique>
(greynolds@datalogics.com)
References: <51ED3F5356D8D011A0B1006097C3073401B16DDD@martinique>
Message-ID: <199909220028.TAA02604@bruno.techno.com>
> I can't resist chipping in my tuppence, since this touches on one of the
> truly horrific aspects of the design of SGML and, yes, Groves. (Feel free
> to ignore my adjectives; I'm in a hyper bolic mood.)
> > I would conclude that attributes were a truly unfortunate
> > decision, and we
>
> Not the fact of attribution, but the horrible way in which it is modeled,
> for which we can thank SGML. "Groves" is even more monstrous in its
> treatment of this.
Surely you meant to say: "The *SGML Property Set* is even more
monstrous in its treatment of this." (:^)
The grove paradigm, when used, is always exactly as monstrous (or as
elegant) as the property sets that are being used with it.
-Steve
--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com http://www.techno.com ftp.techno.com
voice: +1 972 231 4098
fax +1 972 994 0087
pager (150 characters max): srn-page@techno.com
3615 Tanner Lane
Richardson, Texas 75082-2618 USA
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)
From tyler at infinet.com Wed Sep 22 02:30:53 1999
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun 7 17:15:26 2004
Subject: RFC: Attributes and XML-RPC
References:
Message-ID: <37E8235C.40861E85@infinet.com>
Erik James Freed wrote:
> My thinking is that it is considered harmful to have two ways of doing
> such semantically equivalent things, because this can easily lead to more
> complicated implementations
> and more complicated interfaces than is optimal. This rule of course can be
> immediately broken if there is some truly useful distinction between the two
> (they are not truely equivalent). The case
> Tim is making for breaking this rule is one of readability e.g. that
> attributes are more readable for certain features. Presumably this
> readability advantage would diminish and reverse where attributes are long
> enough to really want to be on multiple lines. So you have a feature where
> the lenght of the string representing the value determines an implementation
> change (kind of fugly as data modeling goes). I can see either side, but I
> think that
> readability is a troublingly subjective metric. Another argument is that
> this seemingly small semantic aliasing may cause more problems in the future
> as new features are added. Note the effect on query languages for instance.
> God knows they need all the help they can get to limit complexity.
>
> I would conclude that attributes were a truly unfortunate decision, and we
> will live to regret it more in the future, but does the impact of this
> decision have enough of an force to reverse a long standing language
> feature? I kind of doubt it, I bet that there is now enough cultural
> momentum to prevent that.
Personally I think it is bad practice to contain data that an application uses directly like a
price, or a coordinate even though it is probably more intuitive to read:
0
0
0
0
A rectangle will never really change and you cannot really extend a rectangle. But attributes
are very useful for describing the context with which the element should be treated, for
example namespaces. Namespaces nodes as they are called in XSLT are not really relevant to the
application itself but delimit the scope of a "namespace" and
define what the namespace prefix actually means. Really, I would of prefered to delimit
namespace scopes using PI's as in the long run I think would of been much more extensible and
not so obtrusive, but that is a debate that has been rehashed over and over again and with no
success. But it would be nice if namespaces were defined by PI's so that only the XML parser
needs to deal with the PI's when constructing a QName and let the application do whatever it
wanted with attributes to describe the context of an element AS IT APPLIES TO THE APPLICATION
PROCESSING IT, if anything.
If you are going to actually use "Namespaces in XML" you are probably better off not using
attributes at all so that if someone actually looked at your element tree, they could choose
to ignore attribute processing altogether instead of having to check each attribute to see if
it is a namespace node before presenting it to the application.
I myself would rather use a namespaces solution that works (even if non-standard and home
brewed) than something which is totally broken in concept as well as implementation.
Tyler
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)
From tyler at infinet.com Wed Sep 22 02:44:12 1999
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun 7 17:15:26 2004
Subject: RFC: Attributes and XML-RPC
References: <00b901bf0482$b60677c0$0a0a0a0a@deltabiz>
Message-ID: <37E82697.8E88466F@infinet.com>
Several compression formats would in effect eliminate any significant difference between using
elements or attributes. One compression format that comes to mind is LZW, but it is too bad
that it is patented by the people "Who eat, sleep, and drink this stuff" (-:
Steven Livingstone wrote:
> > Would it not also be true that using attributes rather than elements can
> > also be more efficient in certain situations?
> >
> > In XML messaging for example, would it not be more efficient to use
> > attributes accross the wire.
> >
> > Consider
> >
> >
> > Steven
> >
> > 24
> >
> > 1.87
> >
> > 7
> >
> >
> >
> > and an equivalent with attributes
> >
> >
> >
> > The first has 79 characters and the second has 52. If we transferred 10
> > peoples information accross the wires, we would need 270 "redundant"
> > characters (2700 with 100 persons) !! 10 persons *is not* a lot of data
> for
> > the applications I often write.
> >
> > In the world of transferring data across the wire, this may be pretty
> > important, especially with the recent converstions on XML-bin (binary XML)
> > and the desire to speed up XML.
> >
> > Does everyone disagree?
> >
> > Cheers
> > Steven
> >
> > Steven Livingstone
> > Glasgow, Scotland.
> > +44 7771 957 280
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)
From tyler at infinet.com Wed Sep 22 02:57:12 1999
From: tyler at infinet.com (Tyler Baker)
Date: Mon Jun 7 17:15:26 2004
Subject: RFC: Attributes and XML-RPC
References: <005901bf044c$da269350$788410d2@tigue.oz.net> <199909211621.MAA32402@hesketh.net> <003e01bf0451$86297830$1618ccce@pebbles> <37E81E75.C8B49852@allette.com.au>
Message-ID: <37E82964.E0D641CC@infinet.com>
Marcus Carr wrote:
> Dave Winer wrote:
>
> > Attributes are for wispy little very optional things, if they are for
> > anything at all.
>
> Wispy little things like security levels? How would you represent the following pseudo-defence
> data:
>
>
> Wheeled Armoured Toys
>
> WATs are your friend...
>
>
>
> The two options that come to mind are either:
>
>
> u
> Wheeled Armoured Toys
>
> u
> WATs are your friend...
> u
>
>
>
> ... which requires the evaluation of a child element before the application is able to
> understand how to deal with an elements such as para0 or para, (presumably the values are
> inherited) or something like:
>
>
>
> Wheeled Armoured Toys
>
>
>
> WATs are your friend...
>
>
>
>
>
>
> ... which obviously requires a ridiculously loose content model for element u and any other
> value that may have been assigned to the security level.
>
> I find attributes to be cleaner to look at and more logical to apply than elements, though I
> admit that the nature of the data may blur this distinction. Perhaps consideration of the
> diverse nature of data might have lead you to word your (copied) opening statement less
> emphatically?
I agree. In object to element mappings in an application, I have found it useful to think of
attributes as arguments passed to the constructor of the object you are creating and the child
elements of the containing element to be the properties of the containing element. But approach
number 2 I think is much more extensible since attributes can ony contain primitive type values
unless of course the attribute is just used as a pointer to some other element.
Tyler
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)
From mrc at allette.com.au Wed Sep 22 04:06:58 1999
From: mrc at allette.com.au (Marcus Carr)
Date: Mon Jun 7 17:15:26 2004
Subject: RFC: Attributes and XML-RPC
References: <005901bf044c$da269350$788410d2@tigue.oz.net> <199909211621.MAA32402@hesketh.net> <003e01bf0451$86297830$1618ccce@pebbles> <37E81E75.C8B49852@allette.com.au> <37E82964.E0D641CC@infinet.com>
Message-ID: <37E83A53.8F58138F@allette.com.au>
Tyler Baker wrote:
> I agree. In object to element mappings in an application, I have found it useful to think of
> attributes as arguments passed to the constructor of the object you are creating and the child
> elements of the containing element to be the properties of the containing element.
Yes, I think I consider them along similar lines.
> But approach
> number 2 I think is much more extensible since attributes can ony contain primitive type values
> unless of course the attribute is just used as a pointer to some other element.
I asuume that you meant this example:
u
Wheeled Armoured Toys
u
WATs are your friend...
u
I agree that it is very extensible and in many cases would be adequate, but I still feel that it
lacks some of the rigidity that atttributes offer - for example what would the status be of the
processing instruction in the following (incomplete) fragment?
c
Wheeled Armoured Toys
u
Would it inherit the "c" classification from the ancestor security element or would "u" be applied
because it exists inside the para0 element? Should the application apply the value to everything
that occurs in the parent element, or does the security element act more like a switch? The same
argument can't be made for the evaluation of processing instructions between elements containing an
attribute, because the processing instruction always occurs inside an element, so it can inherit the
value (or lack thereof) from that element.
--
Regards,
Marcus Carr email: mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia) www: http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
- Einstein
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)
From distobj at acm.org Wed Sep 22 05:12:28 1999
From: distobj at acm.org (Mark Baker)
Date: Mon Jun 7 17:15:26 2004
Subject: Xml Messaging
In-Reply-To: <004301bf0463$7b143ae0$0264a8c0@pompano.net>
Message-ID: <3.0.2.32.19990922001158.00de375c@pop1.sympatico.ca>
>should XML messaging be based
>on a "metadata" language, or on a "domain" language?
IMHO, both.
>Method 2: "Domain" language
>-------------------------------------------------------------------
>
>
>
> Bank Account
> Asset
>
> USD
> 15000.00
>
>
>
>
That's sort of both, in that "update" is a metastatement about what is
intended of the document (which appears to be comprised of the content
starting at the GlAccount tag).
Your previous method 1 example requires a translation process that appears
unnecessary. Just dump the document (the account) over the wire with
sufficient context for it to have the desired effect on the other end.
>
>These two methods contrast the "Xml-Rpc" type approach, which I feel
>is not appropriate for all areas of distributed client/server systems
>(in the same way I feel CORBA and COM are sometimes touted
>incorrectly). This opinion is based on another which says that
>clients use data differently than servers, and so clients should not
>be exposed to a server's fine-grained APIs, nor the object model(s)
>thereof.
>
Right. Ditto for SOAP. State transfer, not method invocation.
MB
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)
From eliot at isogen.com Wed Sep 22 05:25:52 1999
From: eliot at isogen.com (W. Eliot Kimber)
Date: Mon Jun 7 17:15:26 2004
Subject: multidirectional links with XLINK
References: <37E789B2.F9E3393E@uni-koblenz.de>
Message-ID: <37E852CC.13BEC9EF@isogen.com>
Friedhelm Krebs wrote:
>
> Reading the X-Link-Specification I found the keyword
> multidirectional-link, but I had no idea how to realize it with X-Link.
> What?s the difference to, for instance, two uni-directional links, one
> on each side?
The difference is that in the first case you are asserting one
relationship between the two things and in the second you are asserting
two relationships. The "directionality" of the links is merely a matter
of behavioral style.
In XLink, a hyperlink is an object that asserts a relationship among two
or more things ("resources"). The existence of this relationship can be
used for many purposes, only one of which is to enable navigation within
a browsing environment.
Because all links (simple or extended) assert relationships among
things, they are all inherently multidirectional in the sense that
knowing both ends you can move from one to the other without restriction
in the general case. It doesn't (or shouldn't) matter which end is the
link element itself--one the link is resolved you know where both ends
are.
However, it is often useful or necessary to limit movement to only one
direction across the relationship, either because the semantics of the
link require it or because practicalities of the browsing environment
demand it.
For example, if you are using links to represent connections between
rooms in a roll-playing game (think of the old Zork classic), you could
represent doors that lock behind you with links that only allow
traversal in one direction.
In a Web environment, it is usually not practical to examine every
document to find all the link elements before enabling movement from one
end to the other, so you can only allow traversal from one end, the end
that is the link, to the other in the normal case (this is why HTML
links appear to be so limited--they have to be given the operating
environment they are designed for).
But note that these uni-directional limitations are artificial. In the
abstract, there is no reason you can't always traverse in both
directions.
Remember too that given both simple and extended links, there are always
three possible syntactic configurations for the same relationship:
1. Link is resource 1 and points to resource 2 (simple, extended acting
as one of its resources)
2. Link is resource 2 and points to resource 1 (ditto)
3. Link is not a resource and points to resources 1 and 2 (extended not
one of its own resources)
Any one of these three configurations can always be converted to either
of the other two without information loss. Each one of these
configurations will be best suited to a particular use scenario.
If you have two unidirectional links, you have redundant information
because if both links connect the same resources then you have defined
the same relationship twice. Of course, if all you care about is
enabling browsing in a Web environment, that may be all you can do.
Cheers,
E.
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)
From ricko at allette.com.au Wed Sep 22 05:50:03 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:26 2004
Subject: (Off topic) Shaken not stirred
Message-ID: <00aa01bbf79a$9e16f6f0$3ff96d8c@NT.JELLIFFE.COM.AU>
Thanks for the email from people on this list enquiring how I fared in
our earthquake.
I can report that a 7.9 earthquake causes even more agitation than three
namespaces.
(Actually, it was only 4.9 by the time it got up here; it physically
agitated but people
kept calm. Next day, all the old men were so happy: to have cheated
death again
I suppose.)
Rick Jelliffe
Taipei, Taiwan
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)
From cbullard at hiwaay.net Wed Sep 22 06:07:15 1999
From: cbullard at hiwaay.net (Len Bullard)
Date: Mon Jun 7 17:15:27 2004
Subject: newbie-ish DTD question: am i asking too much of XML, or of my brain?
References: <01BF0469.A754E860@grappa.ito.tu-darmstadt.de>
Message-ID: <37E8521E.232@hiwaay.net>
Ronald Bourret wrote:
>
>
>
Gad it is so good to see someone posting element type declarations.
Refreshing.
len
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)
From ricko at allette.com.au Wed Sep 22 06:13:48 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:27 2004
Subject: What XHTML should do with namespaces
Message-ID: <00ba01bbf79e$0ef8cb20$3ff96d8c@NT.JELLIFFE.COM.AU>
From: John Cowan
>Rick Jelliffe scripsit:
>
>> 1) There should be three namespaces:
>> base
>> slack
>> frames
>>
>> 2) These namespace should be formally defined by means of a simple
>> list in each case, so that every HTML 4 element is allocated to one
only
>> namespace each.
>
>Doesn't work. Transitional doesn't just add new elements to Strict,
>it adds new attributes for the old elements. Frameset differs because
>it has different content models from Transitional.
Frameset only only differs from transitional at the top level. In other
words
There is no necessity to give any element types apart from the frameset
element
type a special namespace (assuming even that is necessary). If you give
html a different namespace if the document uses framesets, it only gains
you
maybe 20 or 30 characters from when you would find out that you were
using
framesets anyway.
As for transitional versus strict, the DTD is not a function of the
element type
name, so it does not matter that strict DTDs attach different attributes
than
transitional DTDs.
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/ 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)
From ricko at allette.com.au Wed Sep 22 06:36:19 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:27 2004
Subject: Elements cannot be described more than once in DTD, right ?
Message-ID: <00cc01bbf7a1$2a8b7b00$3ff96d8c@NT.JELLIFFE.COM.AU>
From: Sebastien Sahuc Hello,
>
>I have an element () than can have different set of sub
>element. How can I describe it in DTD ?
>
>For example :
>
>
>
>
>
>and :
>
>
>
>
>
>
>How can I express in DTD that affiliate operations in 'set' and 'get',
>and that merchant has only the 'signup' ?
XML DTDs do not allow parents to influence and element type's content
models.
(You could do this in SGML DTDs to an extent, by using "exclusions".)
So your choices are:
1) Check that you really need to have a generic "operations" element
type.
You can transfer the info that it is an "operation" to an attribute:
This has all the same information, just in different markup positions.
2) Use
and then use XSL or DOM or Perl/Python/OmniMark to validate
your extra constraints.
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/ 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)
From pvelikho at cs.ucsd.edu Wed Sep 22 07:57:24 1999
From: pvelikho at cs.ucsd.edu (Pavel Velikhov)
Date: Mon Jun 7 17:15:27 2004
Subject: Elements cannot be described more than once in DTD, right ?
References:
Message-ID: <37E86FF8.7F1102C7@cs.ucsd.edu>
Sebastien Sahuc wrote:
>
> Hello,
>
> I have an element () than can have different set of sub
> element. How can I describe it in DTD ?
>
> For example :
>
>
>
>
>
> and :
>
>
>
>
>
>
> How can I express in DTD that affiliate operations in 'set' and 'get',
> and that merchant has only the 'signup' ?
>
You cannot. This is a fundamental problem with DTDs, you will have to
declare
operations as (get|set|signup). XSchema can get around this problem.
It is interesting to find out whether this is a serious problem for you,
or
something that you can get around/tolerate.
Pavel Velikhov
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)
From pauramo at yahoo.com Wed Sep 22 08:06:51 1999
From: pauramo at yahoo.com (Perttu Auramo)
Date: Mon Jun 7 17:15:27 2004
Subject: unsubscribe xml-dev
Message-ID: <19990922061055.15396.rocketmail@web304.mail.yahoo.com>
unsubscribe xml-dev
===
-Perttu Auramo
050 522 1282
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
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)
From ricko at allette.com.au Wed Sep 22 08:25:05 1999
From: ricko at allette.com.au (Rick Jelliffe)
Date: Mon Jun 7 17:15:27 2004
Subject: #2 Re: Elements cannot be described more than once in DTD, right ?
Message-ID: <00f901bf04c6$f6cc67d0$3ff96d8c@NT.JELLIFFE.COM.AU>
I forgot another option.
Make one generator-side DTD for data entry
Then transform this for data distribution:
The first gives you strong typing for describing the schema
and the second allows simpler generic operations for using
the data (which is presumably why you want to reuse
the name "operations".)
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/ 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)
From mrc at allette.com.au Wed Sep 22 09:01:21 1999
From: mrc at allette.com.au (Marcus Carr)
Date: Mon Jun 7 17:15:27 2004
Subject: Elements cannot be described more than once in DTD, right ?
References: <37E86FF8.7F1102C7@cs.ucsd.edu>
Message-ID: <37E87F5C.507BC8CC@allette.com.au>
Pavel Velikhov wrote:
> > How can I express in DTD that affiliate operations in 'set' and 'get',
> > and that merchant has only the 'signup' ?
>
> You cannot. This is a fundamental problem with DTDs, you will have to
> declare
> operations as (get|set|signup). XSchema can get around this problem.
I don't think that I'd call this a "fundamental problem" any more than I'd complain about not
being able to translate a (deprecated) SGML content model such as:
(foobar, #PCDATA)
into XML. I can use the XML content model:
(#PCDATA | foobar)*
in absolute comfort, but wary of the fact that I need to do a semantic check to ensure that
I'm conforming to the intention of the original content model. Schemas will provide a tidy way
of rolling the structure and semantic checks together, but the concept is the same.
> It is interesting to find out whether this is a serious problem for you,
> or something that you can get around/tolerate.
I'd be a bit surprised if anyone considered this to be a serious problem and amazed if it was
intolerable. :-) Schemas are interesting and will probably play a big role in times to come,
but I don't believe that they offer anything that can't currently be done by other means.
--
Regards,
Marcus Carr email: mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia) www: http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
- Einstein
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)
From pvelikho at cs.ucsd.edu Wed Sep 22 09:18:26 1999
From: pvelikho at cs.ucsd.edu (Pavel Velikhov)
Date: Mon Jun 7 17:15:27 2004
Subject: Elements cannot be described more than once in DTD, right ?
References: <37E86FF8.7F1102C7@cs.ucsd.edu> <37E87F5C.507BC8CC@allette.com.au>
Message-ID: <37E882F2.4065F722@cs.ucsd.edu>
> > It is interesting to find out whether this is a serious problem for you,
> > or something that you can get around/tolerate.
>
> I'd be a bit surprised if anyone considered this to be a serious problem and amazed if it was
> intolerable. :-) Schemas are interesting and will probably play a big role in times to come,
> but I don't believe that they offer anything that can't currently be done by other means.
>
Well, theoretically they are pretty serious problems. If you want to
take a union of DTDs,
say when integrating two XML databases, you might end up with a DTD that
allows a lot of
junk elements, while the original DTDs were strict enought. In the
database setting, when
the DTDs are used as database schemas, this leads to all sorts of
problems.
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)
From mrc at allette.com.au Wed Sep 22 09:36:25 1999
From: mrc at allette.com.au (Marcus Carr)
Date: Mon Jun 7 17:15:27 2004
Subject: Elements cannot be described more than once in DTD, right ?
References: <37E86FF8.7F1102C7@cs.ucsd.edu> <37E87F5C.507BC8CC@allette.com.au> <37E882F2.4065F722@cs.ucsd.edu>
Message-ID: <37E8879A.806CFE23@allette.com.au>
Pavel Velikhov wrote:
> Well, theoretically they are pretty serious problems. If you want to
> take a union of DTDs,
> say when integrating two XML databases, you might end up with a DTD that
> allows a lot of
> junk elements, while the original DTDs were strict enought. In the
> database setting, when
> the DTDs are used as database schemas, this leads to all sorts of
> problems.
Would you not use namespaces to distinguish the fragments originating from the two structures? I
would have thought this was a natural use for them - the simple disambiguation of names so as to
prevent clashes. I wouldn't care that I have more elements than I need because a:foo and b:foo have
identical content models, because it would all have been generated anyway. Could you provide an
example of a DTD being required to allow junk elements? Am I missing something?
--
Regards,
Marcus Carr email: mrc@allette.com.au
___________________________________________________________________
Allette Systems (Australia) www: http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
- Einstein
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)
From msabin at cromwellmedia.co.uk Wed Sep 22 10:45:43 1999
From: msabin at cromwellmedia.co.uk (Miles Sabin)
Date: Mon Jun 7 17:15:27 2004
Subject: XHTML and the Three Namespaces
Message-ID:
Andrew Layman wrote,
> [snip: characterization of the 3 NS position as a
> workaround for XMLs lack of subtyping/inheritance ]
This looks like a sound analysis to me.
> Of the alternatives that I have seen, only the
> proposal for three distinct namespaces seems to have
> sufficient information in it.
Perhaps so, but: it's the wrong way to do it; it
overloads namespaces with baggage they were never
intended to carry; and it preempts schemas which will
(I believe) address this issue properly, possibly in
a way that will make the development of schemas even
harder than it is already.
In short it's a grotty hack that'll store up more
problems for the future than it solves in the present.
FWIW, my take on this is that the HTML WG should
on this issue now, revert to a single namespace, and
return to the problem when schemas are done and
provide the resources to deal with it properly.
Cheers,
Miles
--
Miles Sabin Cromwell Media
Internet Systems Architect 5/6 Glenthorne Mews
+44 (0)181 410 2230 London, W6 0LJ
msabin@cromwellmedia.co.uk England
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)
From ldodds at ingenta.com Wed Sep 22 11:41:54 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun 7 17:15:27 2004
Subject: Summaries please! (RE: We gotta break up these digests)
In-Reply-To: <004401bf0451$f36e7df0$1618ccce@pebbles>
Message-ID: <001501bf04de$de94ae80$ab20268a@pc-lrd.bath.ac.uk>
> It's really simple, XML-DEV needs a weblog.
[snip]
> It would be great if someone could point to all the major postings on this
> list from the web on a daily basis.
This is a neat idea, but I guess the same arguments apply - who
has the time to produce it?
That said it seems that the best way to solve the problem is to
start breaking it into smaller pieces. So I decided that *I* could
benefit from the list by taking some time to pick out the core arguments,
and interesting tidbits. So I started chucking up
some links on my userland weblog (http://my.userland.com/viewChannel$1079).
I don't intend to do much summarising, I don't feel editorially qualified
to do so, but just adding the links I have done have forced me to think
a bit harder about the ongoing discussions.
Might not be of any use to anyone else, but there it is.
L.
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)
From steven.livingstone at scotent.co.uk Wed Sep 22 11:52:36 1999
From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM)
Date: Mon Jun 7 17:15:27 2004
Subject: Summaries please! (RE: We gotta break up these digests)
Message-ID: <8DCB90532FF7D211B34400805FD4885373A19E@SENMAIL3>
Wouldn't it be cool if there was some way of intelligently definining what
people write so it would be very simple to get information you were after
;-)
... seriously, has anyone done any kind of work on DTD's or Schema's for
mailing disussions? People would post using these schema's and that way we
could have a simple XML parser which could get the information we wanted
rather than walking through logs etc..
Steven
> -----Original Message-----
> From: Leigh Dodds [SMTP:ldodds@ingenta.com]
> Sent: 22 September 1999 10:43
> To: xml-dev
> Subject: RE: Summaries please! (RE: We gotta break up these digests)
>
> > It's really simple, XML-DEV needs a weblog.
>
> [snip]
>
> > It would be great if someone could point to all the major postings on
> this
> > list from the web on a daily basis.
>
> This is a neat idea, but I guess the same arguments apply - who
> has the time to produce it?
>
> That said it seems that the best way to solve the problem is to
> start breaking it into smaller pieces. So I decided that *I* could
> benefit from the list by taking some time to pick out the core arguments,
> and interesting tidbits. So I started chucking up
> some links on my userland weblog
> (http://my.userland.com/viewChannel$1079).
>
> I don't intend to do much summarising, I don't feel editorially qualified
> to do so, but just adding the links I have done have forced me to think
> a bit harder about the ongoing discussions.
>
> Might not be of any use to anyone else, but there it is.
>
> L.
>
>
> 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)
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)
From philipnye at freenet.co.uk Wed Sep 22 12:11:07 1999
From: philipnye at freenet.co.uk (Philip Nye)
Date: Mon Jun 7 17:15:27 2004
Subject: multidirectional links with XLINK
References: <37E789B2.F9E3393E@uni-koblenz.de> <37E852CC.13BEC9EF@isogen.com>
Message-ID: <37E8AC0D.EB5CD2D8@freenet.co.uk>
"W. Eliot Kimber" wrote:
>
> Friedhelm Krebs wrote:
> >
> > Reading the X-Link-Specification I found the keyword
> > multidirectional-link, but I had no idea how to realize it with X-Link.
> > What?s the difference to, for instance, two uni-directional links, one
> > on each side?
>
> The difference is that in the first case you are asserting one
> relationship between the two things and in the second you are asserting
> two relationships. The "directionality" of the links is merely a matter
> of behavioral style.
>
In theory any link has two ends and so need not be one-way. However in
the practical representation, a simple link has two ends which look
different and it is often not easy or even possible to traverse the link
in the opposite direction.
XLink uses extended links for multidirectional links. Look at sections
4.3 and 5 of the XLink draft for how this works. I do not know the
current status of XLink activity.
Philip Nye
Engineering Arts UK
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)
From steven.livingstone at scotent.co.uk Wed Sep 22 12:32:05 1999
From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM)
Date: Mon Jun 7 17:15:28 2004
Subject: Summaries please! (RE: We gotta break up these digests)
Message-ID: <8DCB90532FF7D211B34400805FD4885373A1AD@SENMAIL3>
Well, maybe it would be a bit of work.
XML would just be ideal for doing what we have been talking about though.
Is anyone working on XML-based email clients? ie. a client which could use a
DTD/Schema to allow you to send "intelligent" emails? I know a server would
be the next step, but a client version would be so useful.
Cheers,
Steven
Steven Livingstone - http://www.deltabiz.com
07771 957 280 or +447771957280
Author -
Professional Site Server 3, Wrox Press
http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002696
Professional Site Server 3.0 Commerce Edition, Wrox Press
http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002505
President, AIP Scotland.
ceo@citix.com
http://www.citix.com
Join Association of Internet Professionals - http://www.citix.com/aip
> -----Original Message-----
> From: Leigh Dodds [SMTP:ldodds@ingenta.com]
> Sent: 22 September 1999 11:23
> To: Steven Livingstone, ITS, SENM
> Subject: RE: Summaries please! (RE: We gotta break up these digests)
>
> > Wouldn't it be cool if there was some way of intelligently definining
> what
> > people write so it would be very simple to get information you were
> after
> > ;-)
>
> Heh, good point.
>
> > ... seriously, has anyone done any kind of work on DTD's or Schema's for
> > mailing disussions? People would post using these schema's and that way
> we
> > could have a simple XML parser which could get the information we wanted
> > rather than walking through logs etc..
>
> Problem is the convenience of using a mail based group is removed (tap
> your comments into a mail app, use your mail app to read the posts),
> unless
> can add support at the back-end to turn a xml post into a standard
> plain-text
> email.
>
> Problem then is how do you author this correctly? A mail template?
> Not all mailers allow you to use templates - Outlook 98 is frustratingly
> difficult to automate in that regard, although *nix based packages might
> be easier to use.
>
> L.
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)
From co at daisybytes.su.uunet.de Wed Sep 22 12:44:22 1999
From: co at daisybytes.su.uunet.de (Carsten Oberscheid)
Date: Mon Jun 7 17:15:28 2004
Subject: RFC: Attributes and XML-RPC
In-Reply-To: <003e01bf0451$86297830$1618ccce@pebbles>
References: <005901bf044c$da269350$788410d2@tigue.oz.net>
<199909211621.MAA32402@hesketh.net>
Message-ID: <3.0.5.32.19990922124805.009b9950@kelly>
[Dave Winer]
>Attributes are for wispy little very optional things, if they are for
>anything at all.
Not true. In a classical document markup environment, attributes are an
important means to separate document content from metadata. It is much
easier to process (and eventually to ignore or filter, e.g. for
displaying/editing content) additional information that is encoded in a
different way than the document's content. XML was made for simple
processing, and attributes can be used to support this.
This content/attribute distinction may be less important for XML-RPC or
other data-exchange XML applications, but these are only one (admittedly
important) part of the XML picture.
.co.
---------------------------------------------- daisy bytes! ---------
Carsten Oberscheid
co@daisybytes.su.uunet.de digital document processing
http://www.pweb.de/daisybytes.su electronic publishing
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)
From nicmila at vscht.cz Wed Sep 22 13:30:51 1999
From: nicmila at vscht.cz (Miloslav Nic)
Date: Mon Jun 7 17:15:28 2004
Subject: XMLized mails (RE: We gotta break up these digests)
References: <8DCB90532FF7D211B34400805FD4885373A1AD@SENMAIL3>
Message-ID: <37E8BE43.4402AA6F@vscht.cz>
The XML listing on xml-dev would be excellent, but there would be
definitively problems with its introductions.
There is a partial solution, which would work as I hope from the
beginning.
Anybody who wishes to say something XMLized can do it, if we agree on
DTD. Then archive can be browsed on daily basis with a Perl script,
which will create valid xml documents from the tagged parts of e-mail.
So if we decide to use e.g. root element XML_DEV
then following bit of text will be extracted from this message into a
file.
.....
.....
The script should assign to each XML_DEV an unique ID, and use this ID
to name the file.
I would be probably ideal, if there would be a site, which would offer
this raw data in the form of xml files so everybody could use them as
he/she wishes.
"Steven Livingstone, ITS, SENM" wrote:
>
> Well, maybe it would be a bit of work.
> XML would just be ideal for doing what we have been talking about though.
>
> Is anyone working on XML-based email clients? ie. a client which could use a
> DTD/Schema to allow you to send "intelligent" emails? I know a server would
> be the next step, but a client version would be so useful.
>
> Cheers,
> Steven
>
> Steven Livingstone - http://www.deltabiz.com
> 07771 957 280 or +447771957280
>
> Author -
> Professional Site Server 3, Wrox Press
> http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002696
> Professional Site Server 3.0 Commerce Edition, Wrox Press
> http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002505
>
> President, AIP Scotland.
> ceo@citix.com
> http://www.citix.com
>
> Join Association of Internet Professionals - http://www.citix.com/aip
>
> > -----Original Message-----
> > From: Leigh Dodds [SMTP:ldodds@ingenta.com]
> > Sent: 22 September 1999 11:23
> > To: Steven Livingstone, ITS, SENM
> > Subject: RE: Summaries please! (RE: We gotta break up these digests)
> >
> > > Wouldn't it be cool if there was some way of intelligently definining
> > what
> > > people write so it would be very simple to get information you were
> > after
> > > ;-)
> >
> > Heh, good point.
> >
> > > ... seriously, has anyone done any kind of work on DTD's or Schema's for
> > > mailing disussions? People would post using these schema's and that way
> > we
> > > could have a simple XML parser which could get the information we wanted
> > > rather than walking through logs etc..
> >
> > Problem is the convenience of using a mail based group is removed (tap
> > your comments into a mail app, use your mail app to read the posts),
> > unless
> > can add support at the back-end to turn a xml post into a standard
> > plain-text
> > email.
> >
> > Problem then is how do you author this correctly? A mail template?
> > Not all mailers allow you to use templates - Outlook 98 is frustratingly
> > difficult to automate in that regard, although *nix based packages might
> > be easier to use.
> >
> > L.
>
> 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)
--
***************************************************************
Dr. Miloslav Nic e-mail: nicmila@vscht.cz
Department of Organic Chemistry TEL: +420 2 2435 5012
ICT Prague (VSCHT Praha) +420 2 2435 4118
FAX: +420 2 2435 4288
****************************************************************
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)
From steven.livingstone at scotent.co.uk Wed Sep 22 14:28:25 1999
From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM)
Date: Mon Jun 7 17:15:28 2004
Subject: XMLized mails (RE: We gotta break up these digests)
Message-ID: <8DCB90532FF7D211B34400805FD4885373A1C6@SENMAIL3>
I was going to suggest something like that myself as I think it would be
useful (at least a start).
I think we need to get some agreement from quite a few people to get some
initiative, but I think what you have suggested is a good idea !!
Let's see peoples opinions on this....
Steven
Steven Livingstone - http://www.deltabiz.com
07771 957 280 or +447771957280
Author -
Professional Site Server 3, Wrox Press
http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002696
Professional Site Server 3.0 Commerce Edition, Wrox Press
http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002505
> -----Original Message-----
> From: Miloslav Nic [SMTP:nicmila@vscht.cz]
> Sent: 22 September 1999 12:32
> To: xml-dev@ic.ac.uk
> Subject: XMLized mails (RE: We gotta break up these digests)
>
> The XML listing on xml-dev would be excellent, but there would be
> definitively problems with its introductions.
> There is a partial solution, which would work as I hope from the
> beginning.
>
> Anybody who wishes to say something XMLized can do it, if we agree on
> DTD. Then archive can be browsed on daily basis with a Perl script,
> which will create valid xml documents from the tagged parts of e-mail.
> So if we decide to use e.g. root element XML_DEV
> then following bit of text will be extracted from this message into a
> file.
>
>
> .....
> .....
>
>
> The script should assign to each XML_DEV an unique ID, and use this ID
> to name the file.
> I would be probably ideal, if there would be a site, which would offer
> this raw data in the form of xml files so everybody could use them as
> he/she wishes.
>
>
> "Steven Livingstone, ITS, SENM" wrote:
> >
> > Well, maybe it would be a bit of work.
> > XML would just be ideal for doing what we have been talking about
> though.
> >
> > Is anyone working on XML-based email clients? ie. a client which could
> use a
> > DTD/Schema to allow you to send "intelligent" emails? I know a server
> would
> > be the next step, but a client version would be so useful.
> >
> > Cheers,
> > Steven
> >
> > Steven Livingstone - http://www.deltabiz.com
> > 07771 957 280 or +447771957280
> >
> > Author -
> > Professional Site Server 3, Wrox Press
> > http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002696
> > Professional Site Server 3.0 Commerce Edition, Wrox Press
> > http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002505
> >
> > President, AIP Scotland.
> > ceo@citix.com
> > http://www.citix.com
> >
> > Join Association of Internet Professionals - http://www.citix.com/aip
> >
> > > -----Original Message-----
> > > From: Leigh Dodds [SMTP:ldodds@ingenta.com]
> > > Sent: 22 September 1999 11:23
> > > To: Steven Livingstone, ITS, SENM
> > > Subject: RE: Summaries please! (RE: We gotta break up these
> digests)
> > >
> > > > Wouldn't it be cool if there was some way of intelligently
> definining
> > > what
> > > > people write so it would be very simple to get information you were
> > > after
> > > > ;-)
> > >
> > > Heh, good point.
> > >
> > > > ... seriously, has anyone done any kind of work on DTD's or Schema's
> for
> > > > mailing disussions? People would post using these schema's and that
> way
> > > we
> > > > could have a simple XML parser which could get the information we
> wanted
> > > > rather than walking through logs etc..
> > >
> > > Problem is the convenience of using a mail based group is removed (tap
> > > your comments into a mail app, use your mail app to read the posts),
> > > unless
> > > can add support at the back-end to turn a xml post into a standard
> > > plain-text
> > > email.
> > >
> > > Problem then is how do you author this correctly? A mail template?
> > > Not all mailers allow you to use templates - Outlook 98 is
> frustratingly
> > > difficult to automate in that regard, although *nix based packages
> might
> > > be easier to use.
> > >
> > > L.
> >
> > 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)
>
> --
> ***************************************************************
> Dr. Miloslav Nic e-mail: nicmila@vscht.cz
> Department of Organic Chemistry TEL: +420 2 2435 5012
> ICT Prague (VSCHT Praha) +420 2 2435 4118
> FAX: +420 2 2435 4288
> ****************************************************************
>
> 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)
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)
From donpark at docuverse.com Wed Sep 22 14:43:26 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun 7 17:15:28 2004
Subject: RFC: Attributes and XML-RPC
In-Reply-To: <37E82964.E0D641CC@infinet.com>
Message-ID: <000001bf04f8$9342eae0$8c1ecca1@w21tp>
I just realized that many visual XML editors use trees to represent XML
documents and normal tree GUI does not have an obvious place for showing
attributes. Some GUI systems are extremely tree/outline oriented which
could cause designers to shun attributes. There are hybrid tree/table
components that can handle attribute better but they look a little too busy
when there are too many attributes.
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
From mnutter at fore.com Wed Sep 22 14:20:36 1999
From: mnutter at fore.com (Mark Nutter)
Date: Mon Jun 7 17:15:28 2004
Subject: Unsubscribe
In-Reply-To: <002501bf0460$b7622fa0$1204320a@300pl>
Message-ID: <4.2.0.58.19990922081214.00c7ff00@pophost1.fore.com>
At 01:40 PM 09/21/99 -0500, WHubbard wrote:
>(un)subscribe xml-dev
But I don't want to unsubscribe xml-dev! And even if I did, I would send
my request to majordomo@ic.ac.uk, and not to xml-dev@ic.ac.uk. And I'd
also leave off the parentheses ;-)
(No offense intended...)
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Mark Nutter,
Internet Applications Developer
FORE Systems
My horoscope says today is a bad day to be superstitious.
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)
From donpark at docuverse.com Wed Sep 22 15:03:41 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun 7 17:15:28 2004
Subject: Summaries please! (RE: We gotta break up these digests)
In-Reply-To: <001501bf04de$de94ae80$ab20268a@pc-lrd.bath.ac.uk>
Message-ID: <000601bf04fb$822db840$8c1ecca1@w21tp>
>This is a neat idea, but I guess the same arguments apply - who
>has the time to produce it?
I believe there is enough interest in this, more so as XML gains popularity,
that an individual can create an ad-supported executive summary style
newsletter. XMLWatch.com? Members of emerging technology community usually
has much higher influence on future purchases so it makes sense.
Reader-base should be fairly diverse as well so it should be very
interesting.
Best,
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
From mnutter at fore.com Wed Sep 22 15:19:43 1999
From: mnutter at fore.com (Mark Nutter)
Date: Mon Jun 7 17:15:28 2004
Subject: RFC: Attributes and XML-RPC
In-Reply-To: <51ED3F5356D8D011A0B1006097C3073401B16DDD@martinique>
Message-ID: <4.2.0.58.19990922083520.00ca4c40@pophost1.fore.com>
At 02:51 PM 09/21/99 -0500, Reynolds, Gregg wrote:
>This is true; but it doesn't apply. Attribution is not the same as
>structure; the problem is not that we have two ways of doing essentially
>the
>same thing, its that we try to model two essentially different things in
>the same way. Getting rid of attributes fixes the wrong problem. XML and
>similar languages represent attempts to model the way we think, and its
>pretty indisputable that the mind (well, the Western mind, in any case)
>thinks about the world in terms of things, their properties, and their
>relations to other things. The warm fuzzy glow Tim has observer comes, I
>suspect, when people find they can think with an artificial language in
>the
>same way they think ordinarily. Or maybe it's the relief they feel when
>they realize that the computer geeks have not rammed yet another round peg
>through a square hole.
>
>A man has red hair and a dog. To suggest that his relationship with his
>hair (or its redness) is no different than his relationship with his dog
>is,
>well, shocking. It's an outrage!
What's so outrageous about it? A man can lose his dog, and he can also
lose his hair, (or his hair can lose its redness :-)
Seriously, the problem I see is that there are many places where it isn't
possible to determine "correctly" (in some precise definition of
"correctness") whether a given piece of data should be an attribute of a
particular element, or a sub-element contained within the element. For
example, I want to model a directory tree where each directory has access
restrictions (as well as files and subdirectories and so on). Is the
"access level" of the directory an attribute of the element, or
is it an element contained by the element? If I make
it an attribute, then I can supply a default value, restrict possible
values to an enumerated list, and make it required -- but each directory
can only have *one* access level (unless we want to get into parsing things
like ACCESS="public+staff+team1+..." -- ick!). If I make it a subelement,
then I can have multiple access levels, but I lose my default and
enumerated values.
Ok, that particular problem does have a solution: for example,
But on the other hand, we could also do:
Is it the nature of "GROUP-ness" to be an attribute of "ACCESS-ness"? Is
one version "correct" and the other "incorrect"? I don't think so.
It seems to me that the current situation is more of an accident than
anything else. Attributes are currently justified because of the fact that
DTD's happen to allow default and enumerated values only for attributes, so
if you need default/enumerated values, you have to use
attributes. Secondly, it happens that a lot of XML/DTD work is being done
by hand, and attributes are less work to type:
Internet Applications Developer
FORE Systems
Guns don't kill people. Bullets kill people.
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)
From mnutter at fore.com Wed Sep 22 15:19:46 1999
From: mnutter at fore.com (Mark Nutter)
Date: Mon Jun 7 17:15:28 2004
Subject: RFC: Attributes and XML-RPC
In-Reply-To: <00b901bf0482$b60677c0$0a0a0a0a@deltabiz>
Message-ID: <4.2.0.58.19990922091220.00cc2e10@pophost1.fore.com>
At 11:43 PM 09/21/99 +0100, Steven Livingstone wrote:
> > and an equivalent with attributes
> >
> >
> >
> > The first has 79 characters and the second has 52. If we transferred 10
> > peoples information accross the wires, we would need 270 "redundant"
> > characters (2700 with 100 persons) !! 10 persons *is not* a lot of data
> > for the applications I often write.
On the other hand, that redundant data ought to compress quite well using
currently available technology. Wouldn't that tend to mitigate the
disadvantage? Suppose, too, that in some hypothetical successor to XML,
the closing tag could be abbreviated to just , saving 15 characters per
record. Now we're down to only 12 extra characters per record. (Ok,
that's pretty much moot, but then again so is attribute-less XML. Just
wagging a flag out there -- this topic is fairly interesting, at least to
me).
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Mark Nutter,
Internet Applications Developer
FORE Systems
Some people are atheists 'til the day they die.
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)
From dave at userland.com Wed Sep 22 15:25:17 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun 7 17:15:28 2004
Subject: RFC: Attributes and XML-RPC
References: <000001bf04f8$9342eae0$8c1ecca1@w21tp>
Message-ID: <01e401bf04fe$e726b0a0$1618ccce@pebbles>
> Some GUI systems are extremely tree/outline oriented which
> could cause designers to shun attributes. There are hybrid tree/table
> components that can handle attribute better but they look a little too
busy
> when there are too many attributes.
Don, being an outliner guy from way back, of course I use outlines to do
XML.
My philosophy there is pretty simple, no fancy stuff, just an outline
containing XML. No problems with attributes or anything else.
If you want to see a screen shot, check this out:
http://www.outliners.com/images/frontier6/prefsDemoWizardOutline.gif
Dave
PS: More info about outliners is at http://www.outliners.com/. If you have a
Mac you can get a free copy of MORE 3.1 there, which was a very nice
outliner, if I do say so myself! It's probably a very good tool for writing
XML code.
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)
From steven.livingstone at scotent.co.uk Wed Sep 22 15:31:55 1999
From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM)
Date: Mon Jun 7 17:15:28 2004
Subject: RFC: Attributes and XML-RPC
Message-ID: <8DCB90532FF7D211B34400805FD4885373A1DA@SENMAIL3>
>On the other hand, that redundant data ought to compress quite well using
>currently available technology.
I suppose that depends on whether you could bank on people to use the same
compression/decompression algorithms (if this is what you mean).
The advantange I see over XML right now is that it is just text - full stop.
Anyone can read it. Could we keep this guarantee w.r.t compression?
I agree there are places where we could save on redundancy - I suppose it
depends on what you need to do.
One thing mentioned on the XML-RPC web discussion is the ease by which an
attribute could be ignored by an implementation which didn't understand it -
not easily new_word> doable using XML elements without effecting
the doc structure (maybe this has already been mentioned?).
Rgds,
Steven
Steven Livingstone - http://www.deltabiz.com
07771 957 280 or +447771957280
Author -
Professional Site Server 3, Wrox Press
http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002696
Professional Site Server 3.0 Commerce Edition, Wrox Press
http://www.wrox.com/Consumer/Store/Details.asp?ISBN=1861002505
> -----Original Message-----
> From: Mark Nutter [SMTP:mnutter@fore.com]
> Sent: 22 September 1999 14:18
> To: xml-dev@ic.ac.uk
> Subject: Re: RFC: Attributes and XML-RPC
>
> At 11:43 PM 09/21/99 +0100, Steven Livingstone wrote:
> > > and an equivalent with attributes
> > >
> > >
> > >
> > > The first has 79 characters and the second has 52. If we transferred
> 10
> > > peoples information accross the wires, we would need 270 "redundant"
> > > characters (2700 with 100 persons) !! 10 persons *is not* a lot of
> data
> > > for the applications I often write.
>
> On the other hand, that redundant data ought to compress quite well using
> currently available technology. Wouldn't that tend to mitigate the
> disadvantage? Suppose, too, that in some hypothetical successor to XML,
> the closing tag could be abbreviated to just , saving 15 characters per
>
> record. Now we're down to only 12 extra characters per record. (Ok,
> that's pretty much moot, but then again so is attribute-less XML. Just
> wagging a flag out there -- this topic is fairly interesting, at least to
> me).
>
> -_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
>
> Mark Nutter,
> Internet Applications Developer
> FORE Systems
> Some people are atheists 'til the day they die.
>
>
> 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)
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)
From david at megginson.com Wed Sep 22 15:31:38 1999
From: david at megginson.com (David Megginson)
Date: Mon Jun 7 17:15:28 2004
Subject: Don't forget Robin Cover's site
In-Reply-To: <000601bf04fb$822db840$8c1ecca1@w21tp>
References: <001501bf04de$de94ae80$ab20268a@pc-lrd.bath.ac.uk>
<000601bf04fb$822db840$8c1ecca1@w21tp>
Message-ID: <14312.56039.33631.703419@localhost.localdomain>
Don Park writes:
> >This is a neat idea, but I guess the same arguments apply - who
> >has the time to produce it?
>
> I believe there is enough interest in this, more so as XML gains popularity,
> that an individual can create an ad-supported executive summary style
> newsletter. XMLWatch.com? Members of emerging technology community usually
> has much higher influence on future purchases so it makes sense.
> Reader-base should be fairly diverse as well so it should be very
> interesting.
Don knows this already, but in case anyone's not aware, Robin Cover
has for years run a similar service for both SGML and XML. He doesn't
summarize *all* of the debates, but he does include all of the
announcements and summaries of some of the major discussions (like
attributes vs. elements):
http://www.oasis-open.org/cover/
When I'm having a busy day and am deleting most mailing-list traffic
without reading it, I usually take five minutes to go to Robin's "SGML
and XML News" page to make certain that I haven't missed anything:
http://www.oasis-open.org/cover/sgmlnew.html
All the best,
David
--
David Megginson david@megginson.com
http://www.megginson.com/
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)
From dave at userland.com Wed Sep 22 15:36:28 1999
From: dave at userland.com (Dave Winer)
Date: Mon Jun 7 17:15:28 2004
Subject: RFC: Attributes and XML-RPC
References: <4.2.0.58.19990922083520.00ca4c40@pophost1.fore.com>
Message-ID: <01fa01bf0500$7b73d1b0$1618ccce@pebbles>
>>The "warm fuzzy" feeling you get from attributes may just be relief that
you don't have to type so much! But that's an accidental consequence of
the fact that we have to write our XML by hand--a more automated process
would have no such feelings. Attributes are a shortcut that make XML
easier to code by hand, at the cost of introducing a certain amount of
unavoidable ambiguity regarding how a given piece of data should be
modelled.
Bravo!
Exactly right.
We trade off warm fuzzies for future expandability, when with a little more
thought and another layer, we could have both.
Sometimes software design requires this kind of insight.
In XML-RPC, you almost never look at the payload, and you never write it by
hand.
Other kinds of XML we do write by hand, and in those cases, attributes are
very welcome and nice.
But for the boiler-room applications, the ones that humans never type by
hand, you have to watch out for those trade-offs.
Dave
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)
From michael_champion at ameritech.net Wed Sep 22 15:42:10 1999
From: michael_champion at ameritech.net (Michael Champion)
Date: Mon Jun 7 17:15:29 2004
Subject: XMLized mails (RE: We gotta break up these digests)
References: <8DCB90532FF7D211B34400805FD4885373A1C6@SENMAIL3>
Message-ID: <008c01bf0500$857269b0$88bdb3c7@mccdell>
----- Original Message -----
From: Steven Livingstone, ITS, SENM
To: Miloslav Nic ;
Sent: Wednesday, September 22, 1999 8:21 AM
Subject: RE: XMLized mails (RE: We gotta break up these digests)
> I was going to suggest something like that myself as I think it would be
> useful (at least a start).
>
> I think we need to get some agreement from quite a few people to get some
> initiative, but I think what you have suggested is a good idea !!
>
> Let's see peoples opinions on this....
I think that an XML-ized archive of xml-dev is a great idea! It would not
have to be hosted at ic.ac.uk (a little bot could subscribe to the list,
read, convert, and archive messages anywhere). So we don't REALLY need to
get "agreement from quite a few people" to get going, although obviously the
greater the consensus, the more generally useful such a thing would be.
This sounds like a classic case where we should be eating our own dog food
(both as an XML community and as individual vendors); if we can't put
together an XML-based solution for structuring the information in this
mailing list and making it available to those who need it, we've got a lot
of explaining to do!
Mike Champion
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)
From steven.livingstone at scotent.co.uk Wed Sep 22 15:48:17 1999
From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM)
Date: Mon Jun 7 17:15:29 2004
Subject: Don't forget Robin Cover's site
Message-ID: <8DCB90532FF7D211B34400805FD4885373A1DC@SENMAIL3>
>When I'm having a busy day and am deleting most mailing-list traffic
>without reading it,
I do ths exact same and I am subscribed to 8 mailing lists, but there are
specifc subjects within each list I am interested in and I'm afraid Outlook
search doesn't work that great. For example, I have no idea what "groves"
even are, but I am very intersted in XML-RPC discussions or Namespace
discussions etc...
Is it not time we started to get around this problem?
We are in the right place to at least make a start on it !
Over at BizTalk.org, there is some community work on an intelligent
newsreader to summarise threads on the web site as people like to read
offline. I see no reason why the same ideas could not be used for mailing
lists? Dave@Userland has also used a similar (ish) idea for online
discussion groups using RPC and it works very well.
cheers,
Steven
Steven Livingstone - http://www.deltabiz.com
07771 957 280 or +447771957280
> -----Original Message-----
> From: David Megginson [SMTP:david@megginson.com]
> Sent: 22 September 1999 14:35
> To: 'xml-dev'
> Subject: Don't forget Robin Cover's site
>
> Don Park writes:
>
> > >This is a neat idea, but I guess the same arguments apply - who
> > >has the time to produce it?
> >
> > I believe there is enough interest in this, more so as XML gains
> popularity,
> > that an individual can create an ad-supported executive summary style
> > newsletter. XMLWatch.com? Members of emerging technology community
> usually
> > has much higher influence on future purchases so it makes sense.
> > Reader-base should be fairly diverse as well so it should be very
> > interesting.
>
> Don knows this already, but in case anyone's not aware, Robin Cover
> has for years run a similar service for both SGML and XML. He doesn't
> summarize *all* of the debates, but he does include all of the
> announcements and summaries of some of the major discussions (like
> attributes vs. elements):
>
> http://www.oasis-open.org/cover/
>
> When I'm having a busy day and am deleting most mailing-list traffic
> without reading it, I usually take five minutes to go to Robin's "SGML
> and XML News" page to make certain that I haven't missed anything:
>
> http://www.oasis-open.org/cover/sgmlnew.html
>
>
> All the best,
>
>
> David
>
> --
> David Megginson david@megginson.com
> http://www.megginson.com/
>
> 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)
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)
From mnutter at fore.com Wed Sep 22 15:49:47 1999
From: mnutter at fore.com (Mark Nutter)
Date: Mon Jun 7 17:15:29 2004
Subject: RFC: Attributes and XML-RPC
In-Reply-To: <37E83A53.8F58138F@allette.com.au>
References: <005901bf044c$da269350$788410d2@tigue.oz.net>
<199909211621.MAA32402@hesketh.net>
<003e01bf0451$86297830$1618ccce@pebbles>
<37E81E75.C8B49852@allette.com.au>
<37E82964.E0D641CC@infinet.com>
Message-ID: <4.2.0.58.19990922093959.00b84220@pophost1.fore.com>
At 12:09 PM 09/22/99 +1000, Marcus Carr wrote:
>for example what would the status be of the
>processing instruction in the following (incomplete) fragment?
>
>
> c
> Wheeled Armoured Toys
>
>
> u
>
>Would it inherit the "c" classification from the ancestor security element
>or would "u" be applied
>because it exists inside the para0 element?
Isn't this an improper use of processing instructions? Your question seems
to be concerned with which security attribute the processing instruction
would have, but I did not think processing instructions were supposed to
*have* attributes (or child-elements, for that matter). The security level
ought to be completely irrelevant to the processing instruction, shouldn't
it?
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Mark Nutter,
Internet Applications Developer
FORE Systems
Some people are atheists 'til the day they die.
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)
From mnutter at fore.com Wed Sep 22 15:49:44 1999
From: mnutter at fore.com (Mark Nutter)
Date: Mon Jun 7 17:15:29 2004
Subject: RFC: Attributes and XML-RPC
In-Reply-To: <37E81E75.C8B49852@allette.com.au>
References: <005901bf044c$da269350$788410d2@tigue.oz.net>
<199909211621.MAA32402@hesketh.net>
<003e01bf0451$86297830$1618ccce@pebbles>
Message-ID: <4.2.0.58.19990922092947.00c98210@pophost1.fore.com>
At 10:10 AM 09/22/99 +1000, Marcus Carr wrote:
>The two options that come to mind are either:
>
>
> u
> Wheeled Armoured Toys
>
> u
> WATs are your friend...
> u
(I think this line is superfluous...)
>
>
>
>... which requires the evaluation of a child element before the
>application is able to
>understand how to deal with an elements such as para0 or para, (presumably
>the values are
>inherited)
Whether you evaluate the security level first because it's an attribute or
whether you evaluate it first because it's the first child element, you're
still going to evaluate it before you evaluate the (other) child
elements. Why/how is it worse to deal with it first as a child element
rather than dealing with it first as an attribute?
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Mark Nutter,
Internet Applications Developer
FORE Systems
Some people are atheists 'til the day they die.
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)
From ann at webgeek.com Wed Sep 22 15:52:55 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:29 2004
Subject: XHTML and the Three Namespaces
In-Reply-To: <4454C011BDE5D211B6C800609776E540268339@master.design-intel
ligence.com>
Message-ID: <4.1.19990922095142.02320190@mail.webgeek.com>
At 04:41 PM 9/21/99 -0700, Marc.McDonald@Design-Intelligence.com wrote:
>> :
>>
> Andrew Layman wrote:
>
>> One thing that people would like is to be able to clearly define which
>> documents are valid per the Strict, Transitional and Frameset rules. This
>> is
>> currently done via three DTDs.
>>
>Fine, though I would argue for a single DTD with conditionals.
The task and constraints given to the group was to bring HTML 4.0 as it
was, into XML. That doesn't provide for significant design variations like
moving to a single DTD with conditionals.
New and innovative work is continued into future deliverables, working
drafts currently available to the public.
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From mnutter at fore.com Wed Sep 22 15:58:39 1999
From: mnutter at fore.com (Mark Nutter)
Date: Mon Jun 7 17:15:29 2004
Subject: RFC: Attributes and XML-RPC
In-Reply-To: <3.0.5.32.19990922124805.009b9950@kelly>
References: <003e01bf0451$86297830$1618ccce@pebbles>
<005901bf044c$da269350$788410d2@tigue.oz.net>
<199909211621.MAA32402@hesketh.net>
Message-ID: <4.2.0.58.19990922094946.00d27460@pophost1.fore.com>
At 12:48 PM 09/22/99 +0200, Carsten Oberscheid wrote:
>In a classical document markup environment, attributes are an
>important means to separate document content from metadata.
But when you're writing the DTD, how do you know what is "content" and what
is "metadata"? For example, if you have a genealogy DTD, and you're
representing things like:
Biological father
Biological mother
Location where birth certificate is recorded
Place of birth
Date of birth
...and so on. Which are content, and which are metadata? It seems to me
that there isn't any inherent distinction, but rather an arbitrary
distinction is imposed by the designer at the time the DTD is written.
> It is much
>easier to process (and eventually to ignore or filter, e.g. for
>displaying/editing content) additional information that is encoded in a
>different way than the document's content.
The only problem is that you are more or less locked in to the designer's
original (arbitrary) designations regarding what's content and what's
metadata. If you want to come along after the fact and do some ad hoc
processing (supposedly one of the advantages of XML), you may very well
find that what's content and metadata for you isn't quite the same as what
the original designer thought of as content and metadata. At that point,
the content/metadata distinction becomes a liability, rather than an asset.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Mark Nutter,
Internet Applications Developer
FORE Systems
Some people are atheists 'til the day they die.
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)
From mnutter at fore.com Wed Sep 22 15:58:49 1999
From: mnutter at fore.com (Mark Nutter)
Date: Mon Jun 7 17:15:29 2004
Subject: Attributes vs. text content (Was Re: RFC: Attributes and
XML-RPC)
In-Reply-To: <028501bf045c$1de766f0$a24630d1@trivida.com>
References: <3.0.32.19990921090755.00b95a00@pop.intergate.bc.ca>
Message-ID: <4.2.0.58.19990922080342.00cfdcf0@pophost1.fore.com>
At 11:07 AM 09/21/99 -0700, Jeff Greif wrote:
>For certain kinds of applications, I find the opposite style -- attributes
>only and no PCDATA -- works best... It was
>extremely convenient to be able to easily denote which attributes needed
>to
>be present, to provide default values, insist on values from an enumerated
>set (thus avoiding misspellings)...
This is the reason, in a nutshell, why XML needs attributes -- XML (and
SGML) DTD's don't have any mechanism for specifying default/enumerated
values for PCDATA content. But now, suppose we had some kind of standard
schema mechanism that allowed us to say things like "Content must be a
date" or "Content must be numeric" or "Default value is 'Left'" and so
on. If we could constrain the character data contained within an element
in the same way(s) we constrain attributes, would we still need attributes?
Disclaimer: I know various schema proposals are on the table, but I'm not
familiar with any of them.
Oh well, 0.02 international monetary unit's worth...
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Mark Nutter,
Internet Applications Developer
FORE Systems
Today's program was brought to you by the language C and the
number F. A production of CompSci Television Workshop.
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)
From donpark at docuverse.com Wed Sep 22 16:07:18 1999
From: donpark at docuverse.com (Don Park)
Date: Mon Jun 7 17:15:29 2004
Subject: Don't forget Robin Cover's site
In-Reply-To: <14312.56039.33631.703419@localhost.localdomain>
Message-ID: <000a01bf0504$6498b240$8c1ecca1@w21tp>
>When I'm having a busy day and am deleting most mailing-list traffic
>without reading it, I usually take five minutes to go to Robin's "SGML
>and XML News" page to make certain that I haven't missed anything:
Robin's site is also on my daily visit list. What a great site (although I
do wish the pages were little shorter)!
Hmm, maybe if he puts up some ad-banners, he could 'dup' himself to cover
the discussion summaries as well. I don't mind ad-banners if the
information is valuable enough.
Best,
Don Park - mailto:donpark@docuverse.com
Docuverse - http://www.docuverse.com
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)
From scarter at disa.org Wed Sep 22 16:14:53 1999
From: scarter at disa.org (Shirley A. Carter)
Date: Mon Jun 7 17:15:29 2004
Subject: Fwd: RE: (un)subscribe xml-dev
Message-ID: <4.1.19990922095742.0095a570@enterprise.disa.org>
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990922/4106663c/attachment.htm
From ldodds at ingenta.com Wed Sep 22 16:33:19 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun 7 17:15:29 2004
Subject: (un)subscribe xml-dev
In-Reply-To: <4.1.19990922095742.0095a570@enterprise.disa.org>
Message-ID: <002401bf0507$a2b760a0$ab20268a@pc-lrd.bath.ac.uk>
>The attached email shows that I did read the footer. It did not work so I
was >sending the message to every address listed. It still has not worked.
Are you attempting to unsubscribe from an email address that differs
from the address you subscribed with? A recent listadmin message
mentioned that these get require manual intervention and
are processed weekly.
http://www.lists.ic.ac.uk/hypermail/xml-dev/xml-dev-Sep-1999/0575.html
L.
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)
From Mkhaja at chn.cts-corp.com Wed Sep 22 16:52:30 1999
From: Mkhaja at chn.cts-corp.com (Mohideen, Khaja (CTS))
Date: Mon Jun 7 17:15:29 2004
Subject: unsuscribe xml-dev
Message-ID: <697D1663ABD6D1119D880060B0B54563014C393E@CTSINWCBSXUA>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990922/48d824c1/attachment.htm
From ldodds at ingenta.com Wed Sep 22 16:51:34 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun 7 17:15:29 2004
Subject: RFC: Attributes and XML-RPC
In-Reply-To: <4.2.0.58.19990922094946.00d27460@pophost1.fore.com>
Message-ID: <002701bf050a$30d2dac0$ab20268a@pc-lrd.bath.ac.uk>
> At 12:48 PM 09/22/99 +0200, Carsten Oberscheid wrote:
> >In a classical document markup environment, attributes are an
> >important means to separate document content from metadata.
>
> But when you're writing the DTD, how do you know what is
> "content" and what
> is "metadata"? For example, if you have a genealogy DTD, and you're
> representing things like:
>
> Biological father
> Biological mother
> Location where birth certificate is recorded
> Place of birth
> Date of birth
I believe by metadata the original author meant information which should
be used as processing instructions or hints to the application processing
the document. I'd say that none of the items you list fall into that
category
so they're content.
The question of whether attributes *should* be storing this kind
of metadata seems to be another question entirely. If XML is a data format
then why clutter XML documents with processing hints? Couldn't this
data be captured separately in a second document and used alongside
the first? XLinks/Pointers could be used to refer to specific elements.
The 'metadata' is actually data for the processing application.
What happens if you change the processing application, or need more
parameters
or info? Say you started out with a simple attribute, but later on
down the line you need (say) the XML equivalent of a RDBMS data dictionary,
or similar.
Thats not a situation thats likely to arise with an in-house or closed
application and its documents. For something like XML-RPC I think
Dave Winer has taken the right view of being cautious.
Mixing metadata in with data seems IMHO to be (warm :) fuzzy modelling.
I'm certainly guilty of it.
Or am I completely nuts? :)
L.
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)
From ken at bitsko.slc.ut.us Wed Sep 22 16:52:58 1999
From: ken at bitsko.slc.ut.us (Ken MacLeod)
Date: Mon Jun 7 17:15:29 2004
Subject: Xml Messaging
In-Reply-To: "Rick Sanderson"'s message of "Tue, 21 Sep 1999 14:59:48 -0400"
References: <004301bf0463$7b143ae0$0264a8c0@pompano.net>
Message-ID:
"Rick Sanderson" writes:
> I am working on a generic framework for client/server/distributed
> apps, and have decided that XML belongs in the messaging
> subsystem. My question basically boils down to this: should XML
> messaging be based on a "metadata" language, or on a "domain"
> language?
I think you'll find a wide variety of opinions on this one.
Metadata languages are often easier to apply when you don't have
control over the data model of the data you will convert to and from
XML.
If you control the entire usage of your application (clients and
servers) you can easily define a domain language and use that. Most
XML applications that define an XML DTD or schema for their specific
messages are, of course, domain languages.
There are several projects aimed at automatically associating domain
languages with general data models.
My list is out of date, but the following are some examples of each:
* Metadata languages for messaging using XML
* LDO-XML
* SOAP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990922/081d3e2c/attachment.htm
From scarter at disa.org Wed Sep 22 17:15:55 1999
From: scarter at disa.org (Shirley A. Carter)
Date: Mon Jun 7 17:15:30 2004
Subject: unsuscribe xml-dev
Message-ID: <4.1.19990922111035.00965970@enterprise.disa.org>
An HTML attachment was scrubbed...
URL: http://mailman.ic.ac.uk/pipermail/xml-dev/attachments/19990922/b23250e2/attachment.htm
From ann at webgeek.com Wed Sep 22 17:22:12 1999
From: ann at webgeek.com (Ann Navarro)
Date: Mon Jun 7 17:15:30 2004
Subject: [MAILER-DAEMON@nag.co.uk: Returned mail: User unknown]
In-Reply-To: <199909221512.QAA15014@nag.co.uk>
Message-ID: <4.1.19990922111936.0263ad90@mail.webgeek.com>
At 04:12 PM 9/22/99 +0100, David Carlisle wrote:
>But sadly the real danger is that xhtml will be so broken over this
>issue that the whole project is derailed. No one wants to see that
>happen.
>
>Is it worth risking this just to avoid specifying that HTML versions are
>distinguished by the version attribute, rather than by the namespace?
This is where I tend to stop giving credence to arguments. Nothing in this
issue, one or three, will so forever break XHTML that it nukes the entire
project. I believe one is the wrong answer. Some of you believe three is
the wrong answer. But neither will kill it all together.
Hyperbole in (hyperbolic?) arguments simply tunes people out.
Ann
---
Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML
Founder, WebGeek Communications http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education http://www.hwg.org/services/classes
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)
From steven.livingstone at scotent.co.uk Wed Sep 22 17:31:05 1999
From: steven.livingstone at scotent.co.uk (Steven Livingstone, ITS, SENM)
Date: Mon Jun 7 17:15:30 2004
Subject: unsuscribe xml-dev
Message-ID: <8DCB90532FF7D211B34400805FD4885373A21B@SENMAIL3>
>To (un)subscribe, mailto:majordomo@ic.ac.uk the following message
(un)subscribe xml-dev
> -----Original Message-----
> From: Shirley A. Carter [SMTP:scarter@disa.org]
> Sent: 22 September 1999 16:11
> To: xml-dev@ic.ac.uk
> Subject: unsuscribe xml-dev
>
>
>
> **************************************************************************
> ****
> FROM THE DESK OF:
> Shirley A. Carter
> Standards Process Coordinator
> X12 Operations Department
> Data Interchange Standards Association
> (703) 548-7005, EXT. 189 (VOICE)
> (703) 548-7927 (FAX)
> URL: http://WWW.DISA.ORG
Paul
Kathleen
...
In the above, the location where the birth certificate is stored is given
as an attribute of a element, so it's ostensibly
"metadata". Yet, depending on the application that's processing the
information, the location of the physical birth record might very well be
content. Attributes might make sense for a DTD that was intentionally tied
(restricted?) to a predefined process, but isn't part of the strength of
XML supposed to be that the same XML file can be processed in more than one
way? Attributes seem to "fossilize" one particular perspective of the
data, at the expense of alternative ways of looking at the information.
-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Mark Nutter,
Internet Applications Developer
FORE Systems
Some people are atheists 'til the day they die.
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)
From davidc at nag.co.uk Wed Sep 22 17:54:51 1999
From: davidc at nag.co.uk (David Carlisle)
Date: Mon Jun 7 17:15:30 2004
Subject: [MAILER-DAEMON@nag.co.uk: Returned mail: User unknown]
In-Reply-To: <4.1.19990922111936.0263ad90@mail.webgeek.com> (message from Ann
Navarro on Wed, 22 Sep 1999 11:21:30 -0400)
References: <4.1.19990922111936.0263ad90@mail.webgeek.com>
Message-ID: <199909221554.QAA20948@nag.co.uk>
> Nothing in this issue, one or three, will so forever break XHTML
XML and HTML are clearly each unstoppable, so there will clearly be an
XML'ised version HTML. I didn't say that XHTML would break, but the
_project_ ie the control of the system by the W3C HTML WG might be
derailed. If the Recommendations are not workable (or if they fail to
become Recommendations) because of this one technical issue that seems
to me to be a real shame given the large amount of good work that has
clearly gone into the thing. As written I think the draft xhtml specs
are only really usable by XML 1.0 applications that are not namespace
aware. There is really nothing wrong with declaring xhtml to be
an application of XML 1.0 and not mentioning namespaces at all.
That would be preferable to the current proposal.
> This is where I tend to stop giving credence to arguments.
Sadly there isn't much evidence of the WG having given credence to any
of the arguments in the first place. The public rationale document
only really gives one claimed benefit which is fragment use, when
fragments are supposedly deferred to xhtml 1.1, and no explanation is
given as to why a versioning attribute would not solve that case just as
well (or better) than the namespace use proposed.
David
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)
From ldodds at ingenta.com Wed Sep 22 17:56:01 1999
From: ldodds at ingenta.com (Leigh Dodds)
Date: Mon Jun 7 17:15:30 2004
Subject: RFC: Attributes and XML-RPC
In-Reply-To: <4.2.0.58.19990922112435.00a3bc30@pophost1.fore.com>
Message-ID: <003201bf0513$32704800$ab20268a@pc-lrd.bath.ac.uk>
> Yet, depending on the application that's processing the
> information, the location of the physical birth record might very well be
> content.
[snip!]
> Attributes seem to "fossilize" one particular perspective of the
> data, at the expense of alternative ways of looking at the information.
I agree - that was essentially what I was driving at, but probably
less lucidly. :)
The 'metadata' are useful pointers to the processing application.
They're not part of the document content, so shouldn't they be
modelled separately? Either as element content, and make
use of namespaces to clarify their role, or pull 'em out into a
separate document entirely.
L.
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)
From simonstl at simonstl.com Wed Sep 22 18:02:21 1999
From: simonstl at simonstl.com (Simon St.Laurent)
Date: Mon Jun 7 17:15:30 2004
Subject: XHTML and the Three Namespaces
In-Reply-To: <5BF896CAFE8DD111812400805F1991F712E172FB@RED-MSG-08>
Message-ID: <199909221605.MAA03813@hesketh.net>
Based on the subject line, this sounds like 'Goldilocks and the Three
Bears'. I hope that we may come to a happy ending. The last two
paragraphs of this posting are probably the most important part, for those
who just want the conclusion.
At 12:45 PM 9/21/99 -0700, Andrew Layman wrote:
>Here is my understanding of the XHTML namespace problem and its proposed
>solution:
>
>There is a vocabulary and syntax called "Strict". There is another called
>"Transitional", and it includes elements and attributes with the same names
>as those in strict, plus some additional elements and/or attributes, and the
>content models and attribute lists of Transitional are such that any
>document valid under "Strict" is also valid under "Transitional". There is
>also a third grammar called "Frameset" having a similar, superset relation
>to Transitional.
>
>One thing that people would like is to be able to clearly define which
>documents are valid per the Strict, Transitional and Frameset rules. This is
>currently done via three DTDs.
Correct. And in the current draft of XHTML:
[PR, section 3]
PR>This version of XHTML provides a definition of strictly conforming XHTML
PR>documents, which are restricted to tags and attributes from the XHTML
PR>namespaces.
Hence, for all documents that actually conform to this spec, we have a
DOCTYPE declaration that tells us which DTD is appropriate.
>Another thing people would like is to be able to indicate in a document
>which set of rules the document is intended to conform to. This is done by
>giving each of the three grammars a namespace, and saying that the elements
>in each namespace are to be validated against the syntax in the DTD
>corresponding to that namespace.
This is the giant leap that doesn't appear to have any substantial foundation.
1) Why would anyone want to validate XHTML fragments differently according
to the strict/transitional/frameset setup? HTML already has a long
tradition (noted by Tim Berners-Lee in an earlier posting) of 'leave what
you don't understand alone'. If you have handlers for a particular XHTML
tag, great. But does it matter which version of XHTML it came from? I
seriously doubt it.
2) Why does each grammar deserve a namespace in the context which XHTML
purports to be describing? The DOCTYPE declaration already provides this
information.
Section 3.1.2 seems to be out of whack with the rest of the document. If
this document is really about what it claims in 3.1, Document Conformance,
I'd suggest striking 3.1.2.
>This avoids having namespace transitions within a document (as would
>presumably occur if the Transitional namespace contained only those elements
>additive to Strict). This approach also permits each grammar/syntax to be
>described by a DTD, because we know that DTDs do not handle mixing of
>namespaces gracefully. Finally, it allows that existing HTML documents
>without any indication of namespaces, and consequently no namespace
>transitions, may be interpreted according to the broadest grammar.
We already know that DTDs don't handle namespaces gracefully. So why pile
in three namespaces? If for some perverse reason a developer decided to
use all three varieties of XHTML, a validating parser (XML 1.0) would
either choke on the clashing (or missing) namespaces, or face conflicts
because all three DTDs would suddenly occupy the same (internal XML 1.0)
namespace - you can't declare the same element twice...
>But it has the drawback that an element name from Strict and the matching
>element name from Transitional have different URIs, so a namespace-capable
>processor will treat them as of different element types.
Yep. It'll make writing XSL stylesheets a lot more interesting, unless the
writers of XSLT add some kind of extra indirection for namespaces...
>The actual difference between the elements is not sustantially their
>meaning, but only their content models and attribute lists.
Which raises the question, again, of why bother validating this information
against any but the broadest DTD? What benefit could an application get by
validating XHTML fragments, which technically aren't even described by
XHTML 1.0, against three different DTDs?
>[...example in different context...]
>Certainly, interpreting a document incorrectly because we did not read the
>relevant definitions and mappings is not attractive. Nor is it attractive
>to label different element types indistinguishably so that the relevant
>definitions cannot be determined.
I don't think treating strict HTML as transitional for processing purposes
is 'incorrect' in any substantial way. Nor do I think the 'relevant
definitions' in this case are worth the trouble.
>Of the alternatives that I have seen, only the proposal for three distinct
>namespaces seems to have sufficient information in it. Perhaps I have
>overlooked a proposal that also works, but at this point I conclude that the
>burden of proof should rest with those who assert that the three namespace
>approach is faulty, and any such proof should include a demonstration of a
>workable, better alternative approach that actually solves the same problem.
The 'sufficient information' argument seems to come from a very different
valuation of that information. To me, it's much more important to know
that an element is HTML than to know that it is strict, transitional, or
frameset HTML. Having to work harder to find out that it is HTML in order
to accomodate the useless freight of strict/transitional/frameset doesn't
seem like a reasonable tradeoff.
I think this differing valuation is really what lies at the bottom of the
disagreement, and it shows no signs of disappearing. In the end, whatever
the abstract arguments, I think the choice is going to be made based on
which of these 'valuations' is deemed more important.
Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com
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)
From ricks at fourbit.com Wed Sep 22 18:21:30 1999
From: ricks at fourbit.com (Rick Sanderson)
Date: Mon Jun 7 17:15:30 2004
Subject: Xml Messaging
References: <3.0.2.32.19990922001158.00de375c@pop1.sympatico.ca>
Message-ID: <013401bf0516$652cfdd0$0264a8c0@pompano.net>
I Wrote:
> >should XML messaging be based
> >on a "metadata" language, or on a "domain" language?
> >Method 2: "Domain" language
> >-------------------------------------------------------------------
> >
> >
> >
> > Bank Account
> > Asset
> >
> >